[Jersey] Re: stateless REST

From: Martynas Jusevičius <>
Date: Thu, 9 Jun 2016 23:59:18 +0200

Can you clarify what "state" you are talking about? For
authentication/authorization, you can use HTTP headers. What else?

To me, REST is more about query and change of state, not state as such.

I presented paper recently on a similar topic (Linked Data), maybe
you'll find it interesting:

On Thu, Jun 9, 2016 at 11:40 PM, Trenton D. Adams
<> 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 <> 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:
>> 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 <> 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.
>>> 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.