- From: Peter Furniss <peter.furniss@choreology.com>
- Date: Thu, 9 Jan 2003 16:50:29 -0000
- To: "Walden Mathews" <waldenm@optonline.net>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>
> > Yes please. If Mike's description here of the approach is on the right > > lines, it would seem > > to run the risk of holding the form of REST but denying the substance. > There > > could be more > > statefulness here, and held for longer than in the other approaches. > Making > > a URI-distinguished > > resource to hold what is really session state (relevant only to the > > particular client that requested > > the update) doesn't seem to gain much in reality. > > 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. > Addressing the goals directly is an important > simplifying abstraction. Cf. the client trying to figure out how many > update requests are still alive in the network and trying to kill all > the ones it doesn't want to be applied. > These capabilities are needed regardless of what comms stack > you have. It's the meaning of "reliability" at the applications layer. > Regardless of the "reliability" level in the stack, if an application is > written without regard for this end-to-end view of resource state, > it is not "reliable". I agree. Peter
Received on Thursday, 9 January 2003 11:52:56 UTC