Re: Proposed text on reliability in the web services architecture

On Thu, Jan 09, 2003 at 10:27:27AM -0700, Champion, Mike wrote:
> Thanks. Let me put this side by side with the text I wrote:  
> 
> " to the extent that one can
> model a web service using the resource/representation framework, design the
> interaction pattern so that retrievals are "safe" (having no side effects)
> and storage operations are "idempotent" (they can be repeated multiple times
> without changing the state of the resource being updated), then an
> application can simply repeat an operation that fails or whose status is
> uncertain. "
> 
> [Hmm, I'm not a RESTifarian but I can emulate one reasonably well, eh? :-) ]

Yes, that's good.  Sorry, I still haven't read your initial message in
this thread. 8-O

I wanted to relate REST-based reliability to reliable messaging, which I
think the reuse of the message-id mechanism did, to an extent; I think
that's good value-add.

> Differences worth discussing include:
> 
> - You imply that using REST is a matter of wishing to do so, I say it's a
> matter of being able to model a service using resources, representations,
> etc.  I guess I can accept the likelihood that any service could IN
> PRINCIPLE be modeled with REST, but don't some problems lend themselves
> better to REST solutions than others?

Of course.  Our disagreement is a matter of degree; I think a lot more
problems lend themselves to a REST solution than do others in the WG.

>  I guess my wording is a bit too
> negative, yours is a bit too positive, let's try for something neutral.

Hmm, I thought my wording was a bit on the "negative" side too.  Like I
said about the visibility/firewalls comment, I wanted to stay away from
drawing conclusions about the value of REST, because we clearly don't
agree.

But I'm ok with your wording there.

> - This may be a rathole, but I think the essence of the idempotence issue is
> whether the back end is designed to have updates be idempotent, not whether
> it is exposed via HTTP PUT.  A PUT can (empirically) be non-idempotent (e.g.
> into a DBMS where there are side effects such as indexing, although this may
> be RESTifarically incorrect), and a particular bit of code supporting POST
> could be idempotent in fact even if POST is not idempotent in principle.

PUT is always idempotent with respect to the state of the resource.  How
a PUT effects the state of the server is undefined as that snippet that
Ugo quoted said;

   HTTP/1.1 does not define how a PUT method affects the state of an
   origin server.

But the client doesn't care, it can assume idempotent.  If the
non-idempotent side effects of a PUT are significant to the server
owner, they should have designed the system differently and used POST.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis