W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

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

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
Message-id: <008b01c2b824$08f802c0$1702a8c0@WorkGroup>

> > 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT