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

From: Markus Karg <>
Date: Thu, 18 Feb 2010 21:08:37 +0100

What do you mean with "how to sell it to the customers"? All you ask them is
to keep track of their own cart on their client whilst one single visit.
They shall not store anything else. What problem do you expect to get? They
have to keep track of what they like to buy anyways, so it is only few more
information to keep. Don't ask what the benefit for the client is, but ask
what the benefit for the complete system is. REST is nothing your customers
will pay you for, it is an architecture chosen by you as an architect with
respect to a lot of characteristics you have to take care of like
scalability. If you don't like to move your own cart with you while
shopping, don't visit supermarkets! Did Walmart ask the customers what the
benefit of shopping carts are? Or did McDonald's ask hungry people what the
benefit of self-service is? ;-)


The benefit for the customer is that it is rather simple to use for example.
I can use REST much easier than SOAP for example. Compared to a "fancy" http
based solution, REST is clear: You can use it without thinking much about
it, as there will be nothing like a mixed API for example, so possibly you
even don't need a big SDK for the starter use cases.


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


I read thru that thread that Jan posted as well. Seems they are discussing
similar issues... how can we use REST in a RESTful way that adheres to REST
completely so that Roy and Jan and others will agree it is REST... but
maintaining "user" state (I suppose) by using a DB table. I do understand
how storing it in a DB table is no different than storing it in HttpSession
as far as the client is knows. It's stored on the server, regardless of how.


I can actually grasp now after that thread how this works.. I can even see
how it could be beneficial.I like it. BUT.. and Jan/Markus/Roy/et all.. HOW
do we sell it to the client consumers of our RESTful APIs?


Let's say I got this public Cart service. The benefit of it is that you can
stick items into it, use it's payment options to take care of paying for
things, etc. If I transfer the actual storage of the cart data to the
client.. what benefit is it to them? Why would anyone suddenly use my
service.. they now have to keep extra info around, and they have to pass it
back and forth, possibly on every single call.


Let's play this out for a sec.. let's assume I am a client, using this
public cart service. For the sake of this argument, I am a web site
providing a nice "store" for my users. I am behind the scenes (on my server
side) being the client to this public cart service. My first thought as a
developer is that I don't have to deal with storing the cart..there is this
nice service for this. Then I read how to use the cart, and am overjoyed
that I can tell my boss that it's a truly RESTful API. But as I dig a little
deeper (after all I am like 99% of the developers out there that think they
understand REST only to find out as I read more I don't truly understand it
completely), I discover that I in fact have to keep track of the cart data.
What is more, rather than passing a single token/cookie/identifer, I've now
got to pass the growing cart contents back to the server.. to add an item to
it. In return I get the larger cart with my added item and some links
(checkout, cancel, delete, etc).


So the first thing I am thinking (which is in fact how I am thinking right
now after hopefully understanding what you guys are saying about how REST
really should be), is WOW.. I am using (possibly paying) for a service that
really doesn't do much.. I now have to have my server use it's memory to
hold the contents of carts for each user on my site. I am now in need of
scaling out my servers to handle potential load and large consumptions of
memory. So as a java web server kind of developer, I am now going to have to
run a db table to store cart data (avoiding the dreadful HttpSession
replication scaling stuff), and all that jazz. Ugh. Why even bother? If
anything, I'd rather learn how to use Google Checkout, or PayPal and avoid
this nice public cart service. It's more work than it's worth.


My point in all this is that I don't know how I am going to explain to
developers who many have probably dealt with some sort of REST like HTTP
api.. "Everyone has been wrong.. this is a TRUE Rest API and thus the burden
of storing service state is on you buddy.". I just don't know how well that
is going to go over.


So I am left with this feeling that I either continue doing REST the way I
have been.. mostly REST but storing state myself.. but now I can't claim I
am a true REST api becuase Roy and others will bash my REST service (should
it ever take off)... or I can try to explain why developers consuming my API
must do a lot of extra work to use my great service.. most likely scaring
them off from using my service.


Am I way off base? Am I the only one that feels like this? Is there no happy


--- 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, 8:36 AM


Hope I understand the issue. But isn't that why authentication exists?
Carts/orders should have owners and only authenticated owners should be
allowed to update them.

So if concurrency is due to a lack of an authentication mechanism, then I
think this is a different architectural problem. If not, i.e. if multiple
clients that hold the right credentials are allowed to access the service
concurrently, then that's a whole different problem (that I don't believe
posting the complete order will solve, given that multiple clients can POST
complete orders concurrently with potentially unwanted results as well).

Or, perhaps I'm missing the point completely? :)

-- Santiago

On Feb 18, 2010, at 10:03 AM, Jan Algermissen wrote:

> On Feb 18, 2010, at 3:36 PM, Jan Algermissen wrote:
>> On Feb 18, 2010, at 3:32 PM, Jan Algermissen wrote:
>>> for purposes of visibility but I just saw Mark B mentioning that and
cannot give an explanation.
>> Here is the short thread:
> Re-reading that, there are two issues
> - I am not sure I agree and if I do I cannot completely explain on what
> - There indeed is an issue with how much the client wants to rely on the
> maintining stability of the cart (or order) when it comes to
> me hitting 'submit'. IOW, how can I be sure the resource state is the
> when the POST arives as it was when I sent the request
> - the issue has consequences on the design of e.g. the payment 'operation'
> that started this thread.
> Mark's position emphasizes that the complete order should be sent to a
> payment resource instead of invoking a POST-tunneled pay() on the order.
> Jan
>>> Jan
>>>> 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:
>>> -----------------------------------
>>> Jan Algermissen, Consultant
>>> NORD Software Consulting
>>> Mail:
>>> Blog:
>>> Work:
>>> -----------------------------------
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> -----------------------------------
>> Jan Algermissen, Consultant
>> NORD Software Consulting
>> Mail:
>> Blog:
>> Work:
>> -----------------------------------
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -----------------------------------
> Jan Algermissen, Consultant
> NORD Software Consulting
> Mail:
> Blog:
> Work:
> -----------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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