On Feb 18, 2010, at 3:18 PM, Santiago Pericas-Geertsen wrote:
>
> 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.
Correct, that is RESTful. It is just HTTP based remote authoring of the cart.
I think that the actual order submission should be done like
GET /cart
<cart/>
... create order from cart
POST /orders/
<order/>
for purposes of visibility but I just saw Mark B mentioning that and cannot give an explanation.
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/
-----------------------------------