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").

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