- From: Walden Mathews <waldenm@optonline.net>
- Date: Thu, 09 Jan 2003 11:15:03 -0500
- To: Peter Furniss <peter.furniss@choreology.com>, "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"). 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". Walden
Received on Thursday, 9 January 2003 11:37:06 UTC