On Feb 19, 2010, at 2:46 PM, Jan Algermissen wrote:
>
> On Feb 19, 2010, at 2:38 PM, Santiago Pericas-Geertsen wrote:
>
>> Jan,
>>
>> If the meaning of the message must be completely independent of the server's state, then this makes perfect sense. I suppose that orders should include item prices and other information to avoid depending on any other server state.
>>
>> This is a much stronger constraint than session state independence, or simply a different interpretation of what I understood as a session.
>
> The constraint here is stateless messages (AFAICT).
>
>> And it does appear to introduce some complexity for certain systems and may be the reason why many things out there are not REST in this sense.
>>
>> Thanks for the clarification.
>
> Note that this has not yet been backed by the authorities :-)
> It is just what occurred to me yesterday.
From a visibility POV it makes much sense though.
For example, an intermediary can have learned at any time what the semantics of
http://foo/orders are and when it sees a message
POST /orders
<order>
..items..
</order>
it knows what the message means (and can do lots of cool stuff with it).
If, OTH, the service sees
POST /carts/1/buy
Content-Length: 0
the intermediary sees that the meaning is to buy something but not more. It would have to GET /carts/1 to infer that and then all sorts of timing issues arise because the intermediary will never be guaranteed to see the state that the cart was in when the client initiated the POST request.
Looking at it this way it looks pretty obvious.
Jan
>
> Jan
>
>
>>
>> -- Santiago
>>
>> On Feb 19, 2010, at 2:52 AM, Jan Algermissen wrote:
>>
>>> All,
>>>
>>> here is the issue with the POST on the shopping cart to place the order:
>>>
>>> REST constrains messages to be stateless. The meaning of the message must not depend on server side state.
>>>
>>> The meaning of the message depends on the semantics of the resource (which is constrained to be constant over time) but it must not depend on the resource's state at some point in time.
>>>
>>> This is why, in order to correctly reflect the intention to buy A,B and C (see earlier example[1]) these items must be enumerated in the POST body. Just POSTing to the cart resource makes the meaning of the message a function of the semantics of the resource BUT NOT of its current state.
>>>
>>> Jan
>>>
>>> [1] https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=10255
>>>
>>>
>>>
>>> On Feb 18, 2010, at 4:03 PM, 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
>>>>
>>>
>>> -----------------------------------
>>> 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
>>
>
> -----------------------------------
> 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/
-----------------------------------