[Jersey] Re: stateless REST

From: cowwoc <>
Date: Wed, 8 Jun 2016 19:29:04 -0400

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.


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.
> 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.