[Jersey] Re: stateless REST

From: cowwoc <>
Date: Thu, 9 Jun 2016 21:11:44 -0400

JAX-RS != REST. It is one possible implementation of it and it has its

Having worked with REST heavily over the past couple of years I would
say that it is always a lot more work than you'd expect up-front for the
server implementer but that it is actually a pleasure to use from the
client perspective. Of course, this assumes that your REST API is
well-designed, which is actually quite difficult to do.

The main advantages of REST, as I understand it, is that it is far more
scalable and technology-agnostic than the alternatives.

Most people don't need either of those things (how many of you are
building the next Facebook? Trust me, you're not) but it's a nice goal
to strive for.


On 2016-06-09 5: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.