It's really tricky to understand what it really describes.
It means that the server has no knowledge of what the client does next,
once the server finished the response. Only when compiling the
response, the server may include information about what the client
should do next. But it never tells the client what to do in order to
succeed with a subsequent request.
> The client–server communication is further constrained by no client
> context being stored on the server between requests.
Translation: The server has no clue how the client state is, especially
between requests. Within a request, the server only knows what the
server sends. Because of that, the server has to validate everything
again and again, even if the requests are 100% the same.
> Each request
> from any client contains all the information necessary to service the
> request, and session state is held in the client.
Translation: The client must send all the information so the server can
react. That's because the server has no clue what the client state is.
Based on the response and/or client state, the client can decide what
to do.
> 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.
Translation: Your client can send data to the server, that may be
interesting for subsequent requests (like doing a POST to create a
resource, followed by a GET to retrieve it).
I think, the rest is self-explanatory.
One example for a client server application that does not rely on
stateless communication: a terminal application.
Robert
Am Freitag, den 10.06.2016, 13:38 -0600 schrieb Trenton D. Adams:
> 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#Statele
> ss
> 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_contenttr
> ace.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.adams
> > @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.darktech.o
> > rg>
> > > > > 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/html5
> > _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.darkte
> > ch.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-rest-ap
> > plic
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >