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

From: Markus Karg <>
Date: Thu, 18 Feb 2010 21:00:35 +0100

If the only non-RESTful thing in your interface is the cart on the server,
then just get rid of it! Keep the information about a customer between two
visits of your shop on the server (useful since you don't need your VISA
card always but they can send a bill once a month), but drop the idea of
keeping the current cart's info (the information needed to finish one single
shop visit) on the server. See the difference? It's all about what the
information is good for, to remember the client (long-term) or to finish one
single visit (short-term). I don't see that you necessarily *must* break


From: Kevin Duffey []
Sent: Donnerstag, 18. Februar 2010 18:01
Subject: Re: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS
actually means)


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

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: