Re: Proposed text on reliability in the web services architecture [long]

> 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