The only thing you don't get here is recovery.  This scenario works fine as long as both updates succeed.  If one of the updates fails, there's no way to automatically undo the other - at least not with HTTP.  This is because HTTP doesn't have persistent sessions, which distributed transaction processing protocols rely upon to share transaction context.
 
In fact shared, persistent session context is a common attribute of LAN-based communication protocols.  HTTP omits them on purpose since it's WAN-based.  This is the reason we are seeing so many WS-* specifications, basically inventing mechanisms for HTTP to be used in a LAN environment, or perhaps it's better characterized as inside the firewall usage.
 
Eric

----- Original Message ----
From: Ashley at Metamaxim <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, July 3, 2006 12:08:27 PM
Subject: Re: [service-orientated-architecture] RESTful lightbulb

Anne
 
> One approach (for "transfer") might be:

> You have the following resources:
> - Account1
> - Account2
> - TransactionTimeStamp

> The banking application would effect a transfer of $100 from Account1 to Account2:
> - POST Account1 (decrement by 100)
> - POST Account2 (increment by 100)
> - PUT TransactionTimeStamp
 
That makes sense.
 
Thanks
Ashley

__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to