RE: Proposed text on reliability in the web services architecture

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Thursday, January 09, 2003 11:51 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Proposed text on reliability in the web services
> architecture
> 
> 

> "Web services that wish to inherit the properties of the REST
> architectural style, can achieve a degree of reliability 
> without the use
> of some or all of the features of a reliable messaging facility.  For
> example, if the service was to make its data accessible via PUT (an
> idempotent method), then clients can simply reinvoke the method should
> it not be clear if the previous message was successful or not.  For
> non-idempotent methods such as POST, some of the expected features of
> a reliable messaging facility could be reused; specifically, a message
> identifier mechanism."

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? :-) ]

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?  I guess my wording is a bit too
negative, yours is a bit too positive, let's try for something neutral.

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

Thoughts?

Received on Thursday, 9 January 2003 12:28:05 UTC