Re: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS actually means)

From: Kevin Duffey <>
Date: Thu, 18 Feb 2010 09:01:23 -0800 (PST)

Exactly Santiago. Good analogy. I guess I am unclear why we can't use REST with a resource in this manner, avoiding sessions, storing info in the DB, and making the rest of the system stateless all the way across.
So by definition, I can not advertise my service as being RESTful because even tho the actual access to it is via HTTP methods in the same manner as REST, because I store some state on the server side there by making the client's life a lot easier, it is not truly REST. I think this is the main issue that the majority of developers are going to struggle with. Everything else is "rest" but because something like the items in a cart stored on a server side DB... the API breaks the REST rules. That just seems odd to me. Perhaps we can coin a new catchy API name that uses the REST style but allows state management on the server side, one that the industry will adopt and we can all agree on.

--- On Thu, 2/18/10, Santiago Pericas-Geertsen <Santiago.Pericasgeertsen_at_Sun.COM> wrote:

From: Santiago Pericas-Geertsen <Santiago.Pericasgeertsen_at_Sun.COM>
Subject: Re: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS actually means)
Date: Thursday, February 18, 2010, 6:18 AM

On Feb 18, 2010, at 6:02 AM, Kevin Duffey wrote:

> Thanks.. I understand what you mean more so now. I am still not quite sure I see how asking a client to store their "cart" data rather than updating a cart DB on the server side is any less restful. I say that because.. if we can put an item in the cart and remove it from the available items that are stored on the server side... why can't we keep the cart on the server side as well? I understand the notion of statelessness.. but my understanding of that is sort of how servlets and session cookies work.. stateful being the session retains a cookie going back and forth... but moving that HttpSession data to a DB table, while maintaining it's state.. the request/response are stateless. From one request to the next, there is no state.. the logic in the server side has to use something that comes in from the request to figure out the stored state.. in my example, tying the authentication to a user table, then from there being able to get the cart data/state
 from the cart table based on that user. I guess I am unclear as to why this is unRESTful.

 It's unclear to me as well. As long a the service creates a resource identifier for that cart (resource identification in REST), all the client needs to do is use it in subsequent requests. In my view, creating resources identifiers for things of interest is precisely how you avoid relying on sessions. The service will associate that resource identifier with objects stored in a database, and there's no need for the client to store anything once it gets that resource identifier.

 By analogy, let's say you call your insurance company to file a claim. The first time you call, you give them all your info and they give you a claim number (a resource identifier!). Next time you call, it does not really matter who you talk to as long as you give them the claim number and they can look it up in their database. Without a claim number, you'd need to start all over or talk to the same person to continue the session --and that wouldn't very RESTful.

 I'm not sure I can comment on your API specifically, but I believe you can build the system the way you want without relying on sessions.

-- Santiago

To unsubscribe, e-mail:
For additional commands, e-mail: