- From: Walden Mathews <waldenm@optonline.net>
- Date: Thu, 09 Jan 2003 16:14:02 -0500
- To: Peter Furniss <peter.furniss@choreology.com>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
> > It's not about holding session state longer. Assuming a client is > > communicating because it wants to change the state of a resource, > > then the goal of that activity is the resource in some new state. > > Focusing on that problem, REST provides generic methods for > > safely sampling result states (GET) and for directly specifying > > desired end states (PUT), avoiding the risk of multiple-delta application > > (a/k/a "idempotence"). > > this is fine if the client knows what the future state should be. What if > it only knows what it wants done (e.g. buy a wotsit - and the client > typically > buys several wotsits a day). Then session(or invocation) specific resources > or > identifiers are going to be needed. > Maybe, but there are other ways of thinking about it. For instance, if the client knows at the end of the day how many watsits it ordered, then an idempotent update to the order seems appropriate. If the client doesn't know or doesn't care how many watsits it ordered, then reliability is expensive overkill anyhow. If the client prefers to maintain n sessions, though, that's its business, and it's not bad design, long as it's the client maintaining the sessions, not the server. I think we'd find in the real world that the client will somehow maintain its own record of what it ordered, which constitutes the end-state info needed to drive an idempotent interaction. Walden
Received on Thursday, 9 January 2003 16:15:47 UTC