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 medium?
--- 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)
To: users_at_jersey.dev.java.net
Date: Thursday, February 18, 2010, 8:36 AM
Jan,
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: <http://tech.groups.yahoo.com/group/rest-discuss/message/13627>
>
> Re-reading that, there are two issues
>
> - I am not sure I agree and if I do I cannot completely explain on what grounds
> - There indeed is an issue with how much the client wants to rely on the server
> 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 same
> 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: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>> -----------------------------------
>>> Jan Algermissen, Consultant
>>> NORD Software Consulting
>>>
>>> Mail: algermissen_at_acm.org
>>> Blog: http://www.nordsc.com/blog/
>>> Work: http://www.nordsc.com/
>>> -----------------------------------
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>> -----------------------------------
>> Jan Algermissen, Consultant
>> NORD Software Consulting
>>
>> Mail: algermissen_at_acm.org
>> Blog: http://www.nordsc.com/blog/
>> Work: http://www.nordsc.com/
>> -----------------------------------
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> -----------------------------------
> Jan Algermissen, Consultant
> NORD Software Consulting
>
> Mail: algermissen_at_acm.org
> Blog: http://www.nordsc.com/blog/
> Work: http://www.nordsc.com/
> -----------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net