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
>