> Personally, I care very little about scalability. We're not
> facebook, twitter, etc. We would at most scale to 2-3 servers, just
> for redundancy reasons, not load reasons. If I were to scale to 1000
> servers, I'd want to start thinking about sticking very strictly with
> REST principles
REST is not about scale only. It's also about building robust client-
server applications. Robust in terms of evolution and maintainance.
Even simple services should use links a client can navigate on, so the
service can change URIs when desired.
So by following the principles of hypertext, you may end up with less
effort to maintain a set of REST resources after investing into making
them following the principles.
Robert
Am Freitag, den 10.06.2016, 15:11 -0600 schrieb Trenton D. Adams:
> That's just semantics though. For any statefulness to occur, a
> common token would be required. Whether that token is implicit such
> as an IP, or crafted, such as a JSESSIONID, it's still a token none
> the less. So I'm thinking the use of cookies, to send session
> tokens, isn't in keeping with REST principles.
>
> Let's take an example where someone is admitting to a university.
>
> 1. Page 1 contains biographical information, which the student
> submits.
> 2. Page 2 contains program/major information.
>
> In keeping with REST principles, you'd have to submit data from page
> 1, and page 2, on page 2. Alternatively you could commit information
> from page 1 to a database, and simply pass a student ID on page 2
> with the extra info on your program. Both would be in keeping with
> REST principles. Storing page 1 info on the server side, and passing
> just a cookie to identify the session on page 2, is NOT in keeping
> with rest principles. Why? Because it's not scalable. You'd have
> to specifically take action to make sure session state is copied
> between servers. There are technologies for that, but REST is
> intended to avoid the need. Hence transferring the entire state from
> the client to the server on every request, not just a token for a
> session.
>
> Personally, I care very little about scalability. We're not
> facebook, twitter, etc. We would at most scale to 2-3 servers, just
> for redundancy reasons, not load reasons. If I were to scale to 1000
> servers, I'd want to start thinking about sticking very strictly with
> REST principles.
>
> On Fri, Jun 10, 2016 at 2:44 PM, Robert Gacki <robert.gacki_at_contenttr
> ace.org> wrote:
> > Cookies in the scope of HTTP and REST are stateless. It is the
> > "Cookie"
> > header.
> >
> > The client and the server have to agree that data, that is sent via
> > Cookie header, comprises a session that is relevant in subsequent
> > requests (we call it then a "session").
> >
> > So Cookie is just a header and thus 100% stateless.
> >
> > Although, the cookie may be stored on the client and may be send by
> > subsequent requests (following the RFC constraints about domains
> > and
> > paths and expiry and all that stuff). And even this is compliant
> > with
> > the REST principle.
> >
> > So if you use cookies, you are align with the REST principles.
> >
> > Robert
> >
> > Am Freitag, den 10.06.2016, 15:27 -0500 schrieb Tony Zakula:
> > > I would use what works and what is best for you. Standards are
> > > great, but we do not have to be purists in everything we do to
> > get
> > > work done. Jersey still runs on a servlet and you can easily tap
> > > that session if you want to, nothing wrong with that. HTTP that
> > REST
> > > is built on even supports cookies for the session. What is wrong
> > > with mixing and matching a few pieces to make building your app
> > > easy? Nothing. You can even support stateless and state on the
> > same
> > > API calls with Jersey to satisfy different clients. Mobile apps
> > may
> > > store state and web browsers do not. Offer both if needed. Your
> > app
> > > will still work even if you do not adhere to the standard.
> > >
> > > In the end, build an app to fit your use case and that works well
> > for
> > > you.
> > >
> > >
> > > On Fri, Jun 10, 2016 at 2:38 PM, Trenton D. Adams <trenton.d.adam
> > s_at_gm
> > > ail.com> wrote:
> > > > Your descriptions of what REST is what I would like it to be,
> > but
> > > > it isn't that, accrording to most everything I've read on it.
> > If
> > > > you're storing state, you're not using REST. The use of REST
> > > > precludes maintaing state server side. I'm tempted to use JAX-
> > RS
> > > > regardless, and just not use the statelessness part.
> > > >
> > > > https://en.wikipedia.org/wiki/Representational_state_transfer#S
> > tate
> > > > less
> > > > Stateless
> > > > See also: Stateless protocol
> > > > The client–server communication is further constrained by no
> > client
> > > > context being stored on the server between requests. Each
> > request
> > > > from any client contains all the information necessary to
> > service
> > > > the request, and session state is held in the client. The
> > session
> > > > state can be transferred by the server to another service such
> > as a
> > > > database to maintain a persistent state for a period and allow
> > > > authentication. The client begins sending requests when it is
> > ready
> > > > to make the transition to a new state. While one or more
> > requests
> > > > are outstanding, the client is considered to be in transition.
> > The
> > > > representation of each application state contains links that
> > may be
> > > > used the next time the client chooses to initiate a new state-
> > > > transition.[12]
> > > >
> > > >
> > > > On Fri, Jun 10, 2016 at 1:04 PM, Robert Gacki <robert.gacki_at_con
> > tent
> > > > trace.org> wrote:
> > > > > Hi Trenton,
> > > > >
> > > > > I think, you misunderstand what REST is. REST is about how a
> > > > > server and
> > > > > a client interacts to transfer state. The transport itself is
> > > > > stateless
> > > > > ("dumb pipes"). It is an architectural style. The notion of
> > state
> > > > > is
> > > > > something the client and server have to implement themself.
> > What
> > > > > REST
> > > > > describes is nothing else what HTTP specifies, but is not
> > limited
> > > > > to
> > > > > HTTP (think of mail). In fact, Roy Fielding just took HTTP as
> > an
> > > > > example for REST in his dissertation.
> > > > >
> > > > > OSI Layer
> > > > > ----------------------------------------------------
> > > > > | Your server and/or client application | L |
> > > > > ---------------------------------------------- a |
> > > > > | REST as architectural style | y 7 |
> > > > > ---------------------------------------------- e |
> > > > > | HTTP|MAIL|<other req / res based protocols>| r |
> > > > > ----------------------------------------------------
> > > > > Layer 6 and below
> > > > >
> > > > > JAX RS is only about modelling REST principles and Jersey
> > > > > provides the
> > > > > implementation. That does not include state management. So
> > you
> > > > > should
> > > > > see JAX RS as the protocol toolset ("dumb pipes") to build
> > > > > applications. What you call stateful is application state and
> > > > > that is
> > > > > always application / implementation specific. For example,
> > the
> > > > > notion
> > > > > of a session is purely application specific.
> > > > >
> > > > > So Jersey, at its core, does not provide you with components
> > to
> > > > > build
> > > > > things like a wizard. But it provides you the ability to
> > build or
> > > > > use
> > > > > existing components, like JSR 371 and its implementations.
> > > > >
> > > > > To your wizard example: You can solve wizards with different
> > > > > methods.
> > > > > You described one solution, where the server does not store
> > > > > results of
> > > > > previous wizard steps. Each solution has advantages and
> > > > > disadvantages.
> > > > > But all solutions have something in common: they are
> > application
> > > > > specific. If you use HTTP as a communication protocol, you
> > can
> > > > > use REST
> > > > > principles to have a well-defined architectural style. But
> > you
> > > > > still
> > > > > need to figure out how to maintain state between a request
> > and
> > > > > response.
> > > > >
> > > > > An important part of REST is Hypermedia. For HTTP, this is
> > just
> > > > > payload. For an application built by REST principles, it is
> > the
> > > > > state
> > > > > that is transfered. And that state should include all
> > information
> > > > > necessary for server or client to support continous
> > interactions.
> > > > > If
> > > > > you use your browser and surf around, clicking on links or
> > > > > signing in
> > > > > into your Google account, you are doing exactly what REST
> > > > > proposes for
> > > > > all other media types - not just HTML.
> > > > >
> > > > > So your wizard solution is based on HTML (a representation)
> > and
> > > > > is
> > > > > constraint by the HTML specification and how browsers behave.
> > > > > Thus, you
> > > > > may lose form field values when you use the browser's back
> > > > > button. But
> > > > > you can do three things to counter that without storing state
> > > > > server-
> > > > > side (outside request-response bounds): 1) You can provide a
> > back
> > > > > button inside the form that just submits to the server - the
> > > > > server
> > > > > renders the previous page with the values from the hidden
> > fields.
> > > > > 2) In
> > > > > modern browsers, with Javascript enabled, you can store the
> > state
> > > > > client side and restore it when the user goes back. 3) SPAs
> > > > > mostly
> > > > > avoid the problem by avoiding round-trips to the server, with
> > the
> > > > > disadvantage of cloning lots of server-side logic for the
> > client
> > > > > (validation, business logic).
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > Am Freitag, den 10.06.2016, 12:11 -0600 schrieb Trenton D.
> > Adams:
> > > > > > Thanks for the responses guys. I'm thinking more along the
> > > > > lines of
> > > > > > JAX-RS implementations, such as Jersey, providing a
> > template
> > > > > based
> > > > > > approach, where the result can be served by JSP.
> > Technically,
> > > > > that's
> > > > > > almost useless when doing it statelessly, unless your
> > service
> > > > > is
> > > > > > intended to return HTML to a client program, or you intend
> > to
> > > > > violate
> > > > > > the statelessness of REST. Cause like you say, writing
> > BBAs,
> > > > > is
> > > > > > actually quite tough without some nice statefulness.
> > > > > >
> > > > > > JSR 371 will be coming out too. Are they still expecting
> > > > > stateless?
> > > > > > Cause it suddenly becomes less useful. Maintaining all the
> > > > > state in
> > > > > > the browser's store is a lot of extra work, and just a
> > plain
> > > > > weird
> > > > > > way of dealing with it.
> > > > > >
> > > > > > On Fri, Jun 10, 2016 at 10:07 AM, <lenny_at_flowlogix.com>
> > wrote:
> > > > > > > Trenton, I feel your pain.
> > > > > > > In all honesty, the technology architecture didn’t change
> > all
> > > > > that
> > > > > > > much in the last 10 years.
> > > > > > > Don’t get caught up in the Rest/Microservices hype too
> > much.
> > > > > > > For BBAs (boring business apps) which I believe that you
> > are
> > > > > > > dealing with (and I also like developing),
> > > > > > > it makes very little sense migrating to Rest-based
> > > > > architecture.
> > > > > > > Concentrate on cleaning, refactoring, modularizing your
> > code,
> > > > > using
> > > > > > > the latest iterations of Java EE specs that you are
> > already
> > > > > using.
> > > > > > >
> > > > > > > So, why all the hype?
> > > > > > > Current Rest “state-of-the-art” today is actually in it’s
> > > > > very
> > > > > > > infancy. It makes sense for some applications to do it
> > > > > though, but
> > > > > > > not for BBAs.
> > > > > > > What apps does the Stateless Rest APIs make sense for?
> > > > > > > - Multiple clients written separately by different teams
> > > > > (i.e.
> > > > > > > native iOS, native Android, native JavaScript)
> > > > > > > - APIs that other companies use in different (non-Java)
> > > > > languages
> > > > > > > - There are some other use cases also, but the above are
> > the
> > > > > major
> > > > > > > ones
> > > > > > >
> > > > > > > What’s the negative impact of Rest services today, as it
> > > > > relates to
> > > > > > > Java client and server development?
> > > > > > > - Massive violation of DRY principle, as it’s really
> > meant
> > > > > for
> > > > > > > client and server to be written in different languages,
> > > > > > > i.e. client in JavaScript/iOS/Android and server in Java
> > > > > > > - Data models are duplicated both in Java (on the server)
> > and
> > > > > on
> > > > > > > the client (JS/iOS/Android)
> > > > > > > - Validation is duplicated on the client and server
> > > > > > > - Some business logic may need to be duplicated in the
> > client
> > > > > and
> > > > > > > server
> > > > > > >
> > > > > > > The above negatives are something that are not solved by
> > the
> > > > > > > industry quite yet, and for BBAs, (IMHO) is not worth the
> > > > > effort.
> > > > > > >
> > > > > > > As far as answering your specific question, in “pure”
> > Rest
> > > > > API, All
> > > > > > > state is indeed handled by the client, including
> > > > > authentication.
> > > > > > > Authentication is usually handled by “bearer token”
> > paradigm,
> > > > > is
> > > > > > > sent with every request to the server, and thus re-
> > > > > authenticated by
> > > > > > > the server every time.
> > > > > > > Yes, it sounds (and is) a bit less efficient on per-
> > request
> > > > > basis
> > > > > > > (throughput per instance), but does (horizontally) scale
> > > > > better to
> > > > > > > millions of users.
> > > > > > >
> > > > > > >
> > > > > > > > On Jun 9, 2016, at 4:40 PM, Trenton D. Adams
> > <trenton.d.ada
> > > > > ms_at_gma
> > > > > > > > il.com> wrote:
> > > > > > > >
> > > > > > > > One thing I didn't mention, is that I'm considering
> > > > > updating one
> > > > > > > > of our enterprise apps to more modern technologies,
> > where
> > > > > it
> > > > > > > > actually saves effort. It is currently based on RMI,
> > with
> > > > > a
> > > > > > > > custom web front-end/mvc framework based on a the
> > command
> > > > > > > > pattern. So, I'm trying to determine whether we should
> > do
> > > > > EJB or
> > > > > > > > JAX-RS for the back-end, and possibly JAX-RS for the
> > front
> > > > > end.
> > > > > > > > One of the issues is that EJB is almost a drop in
> > > > > replacement for
> > > > > > > > RMI. It would require significant more effort to
> > switch to
> > > > > JAX-
> > > > > > > > RS.
> > > > > > > >
> > > > > > > > When the back end is stateless, it's simply pushing the
> > > > > > > > complexity to the client. It is now the client that
> > must
> > > > > do all
> > > > > > > > the work to know what it needs to send; i.e. it keeps
> > it's
> > > > > own
> > > > > > > > state. For the back end, that's HIGHLY scale-able
> > > > > technology
> > > > > > > > wise, but has other drawbacks. With a stateful back-
> > end,
> > > > > you
> > > > > > > > just set the firstname, lastname, birthdate, etc, and
> > pass
> > > > > around
> > > > > > > > a reference to the back-end object, such as with EJB.
> > > > > Neither
> > > > > > > > the front end nor the back end have to maintain much
> > state,
> > > > > > > > programmatically speaking; it's the service that does
> > that
> > > > > (EJB
> > > > > > > > for example). This saves developer time, does it not?
> > > > > > > >
> > > > > > > > It seems that using the html5 stuff would be a pain in
> > the
> > > > > butt.
> > > > > > > > Mainly because html5's storage system can't store a
> > > > > javascript
> > > > > > > > object even, so you can't even abstract your data
> > storage.
> > > > > Plus,
> > > > > > > > we'd end up not supporting people with older
> > > > > machines/browsers.
> > > > > > > > And then, if you have a series of web pages that a
> > person
> > > > > is
> > > > > > > > going through, you'd have to write code to grab all of
> > > > > that, and
> > > > > > > > pass it to the server.
> > > > > > > >
> > > > > > > > So, should I not use JAX-RS if I'm wanting to maintain
> > > > > state? I
> > > > > > > > mean it kind of goes against the "ST" in REST. Nothing
> > > > > actually
> > > > > > > > prevents you from maintaining state though.
> > > > > > > >
> > > > > > > > I've read some articles where people say you shouldn't
> > even
> > > > > be
> > > > > > > > maintaining state of authentication. That I don't
> > agree
> > > > > with,
> > > > > > > > because some services don't even have access to the
> > user's
> > > > > > > > credentials. So at some point, someone is going to
> > have to
> > > > > > > > maintain state. So, you could either not use JAX-RS,
> > or
> > > > > use it
> > > > > > > > and maintain state while doing so, but essentially
> > violate
> > > > > it's
> > > > > > > > principles.
> > > > > > > >
> > > > > > > > Also, doesn't statelessness become very complex when
> > you
> > > > > have
> > > > > > > > larger enterprise applications?
> > > > > > > >
> > > > > > > > I see a lot of benefits of JAX-RS, and a lot of
> > drawbacks.
> > > > > Am I
> > > > > > > > missing something?
> > > > > > > >
> > > > > > > > On Wed, Jun 8, 2016 at 5:46 PM, cowwoc <cowwoc_at_bbs.dark
> > tech
> > > > > .org>
> > > > > > > > wrote:
> > > > > > > > > Define "application logic".
> > > > > > > > >
> > > > > > > > > In the case you mentioned below (storing the user's
> > last
> > > > > name
> > > > > > > > > somewhere) I would favor using localStorage and
> > > > > sessionStore to
> > > > > > > > > store this information: http://www.w3schools.com/html
> > /htm
> > > > > l5_web
> > > > > > > > > storage.asp
> > > > > > > > > The client would read the information from the local
> > > > > store and
> > > > > > > > > use it to make AJAX calls.
> > > > > > > > >
> > > > > > > > > I misspoke earlier when I talked about Cookies. These
> > are
> > > > > > > > > typically used to reference to a server-side state
> > that
> > > > > is
> > > > > > > > > present across all calls. If some REST calls need one
> > > > > piece of
> > > > > > > > > information and others need another, I would pull
> > them
> > > > > from the
> > > > > > > > > local/sessionStore and pass them to the AJAX calls as
> > > > > needed.
> > > > > > > > >
> > > > > > > > > Gili
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 2016-06-08 7:40 PM, Trenton D. Adams wrote:
> > > > > > > > > > So are you saying push all the application logic to
> > the
> > > > > > > > > > browser, using javascript? Are cookies really
> > intended
> > > > > to
> > > > > > > > > > store a whole bunch of user data?
> > > > > > > > > >
> > > > > > > > > > I know with HTML5, you can use
> > > > > > > > > > sessionStorage.setItem("lastname", "last name").
> > But,
> > > > > I
> > > > > > > > > > don't think moving most application logic into a
> > > > > browser is
> > > > > > > > > > very maintainable, maybe I'm wrong though.
> > > > > > > > > >
> > > > > > > > > > On Wed, Jun 8, 2016 at 5:29 PM, cowwoc <cowwoc_at_bbs.
> > dark
> > > > > tech.o
> > > > > > > > > > rg> wrote:
> > > > > > > > > > > Without commenting on the specifics of Jersey, I
> > > > > agree:
> > > > > > > > > > > REST is for computers, not humans.
> > > > > > > > > > >
> > > > > > > > > > > I typically expose REST APIs for computers and
> > use
> > > > > cookies
> > > > > > > > > > > to maintain browser sessions. The browser can
> > then
> > > > > read
> > > > > > > > > > > stateful information from the Cookie and serve it
> > to
> > > > > > > > > > > stateless REST APIs. Not all clients are web-
> > > > > browsers, so
> > > > > > > > > > > your REST API should be designed around non-
> > browsers.
> > > > > > > > > > >
> > > > > > > > > > > Gili
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 2016-06-08 5:58 PM, Trenton D. Adams wrote:
> > > > > > > > > > > > Good day,
> > > > > > > > > > > >
> > > > > > > > > > > > I'm a bit confused. I actually have two
> > separate
> > > > > > > > > > > > questions. I understand that REST is supposed
> > to
> > > > > be done
> > > > > > > > > > > > in a stateless way. For regular web services
> > > > > that's
> > > > > > > > > > > > easy. I mean it really shifts a lot of the
> > work to
> > > > > the
> > > > > > > > > > > > client, where it seems to be more difficult to
> > deal
> > > > > with,
> > > > > > > > > > > > but as far as the server goes, it's simple.
> > > > > > > > > > > >
> > > > > > > > > > > > However, how is it even possible to use jersey
> > > > > templates
> > > > > > > > > > > > without state (sessions), in a reasonable way?
> > The
> > > > > > > > > > > > browser isn't going to maintain the state. It
> > > > > seems that
> > > > > > > > > > > > one would need to make sure each and every page
> > > > > puts
> > > > > > > > > > > > hidden inputs from the previous form, in the
> > html
> > > > > output,
> > > > > > > > > > > > so that it is re-submitted with the new
> > request.
> > > > > That
> > > > > > > > > > > > would be a lot of work. If the user presses
> > the
> > > > > back
> > > > > > > > > > > > button, all that state vanishes, and the user
> > must
> > > > > re-
> > > > > > > > > > > > enter any screens they go forward to again.
> > This
> > > > > doesn't
> > > > > > > > > > > > make for a very good user experience.
> > > > > > > > > > > >
> > > > > > > > > > > > Can someone explain to me how the use of JAX-RS
> > as
> > > > > an MVC
> > > > > > > > > > > > framework is even possible in a reasonable way,
> > > > > while
> > > > > > > > > > > > being stateless?
> > > > > > > > > > > >
> > > > > > > > > > > > Then, can someone explain to me how
> > statelessness
> > > > > in a
> > > > > > > > > > > > back-end REST web service, promotes good code
> > > > > design,
> > > > > > > > > > > > where user interaction is a necessity? It
> > seems to
> > > > > me
> > > > > > > > > > > > that the client would then need to maintain all
> > the
> > > > > > > > > > > > state, thereby tightly coupling all the data
> > points
> > > > > > > > > > > > between the different controllers on the
> > client.
> > > > > > > > > > > > Something like EJB allows you to pass around
> > the
> > > > > stateful
> > > > > > > > > > > > pointer, and you simply add data as you go.
> > > > > > > > > > > >
> > > > > > > > > > > > After reading this stack exchange post, it's
> > > > > sounding
> > > > > > > > > > > > like everyone thinks that REST is NOT for
> > users,
> > > > > but for
> > > > > > > > > > > > services only.
> > > > > > > > > > > > http://stackoverflow.com/questions/3105296/if-r
> > est-
> > > > > applic
> > > > > > > > > > > > ations-are-supposed-to-be-stateless-how-do-you-
> > > > > manage-
> > > > > > > > > > > > sessions
> > > > > > > > > > > >
> > > > > > > > > > > > I understand that it's more scalable, as the
> > server
> > > > > > > > > > > > always knows exactly what you want, because
> > you're
> > > > > > > > > > > > telling it every time. But it seems like that
> > > > > would come
> > > > > > > > > > > > with a lot more boilerplate coding.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> >