Re: Comments about http://www.w3.org/DesignIssues/Architecture#Conten t : is GET the only idempotent method

> http://www.w3.org/DesignIssues/Architecture#Content
> "The introduction of any other method apart from GET which is idempotent is
> also incorrect, because the results of such an operation effectively form a
> separate address space, which violates the universality."
> 
> I though that PUT was idempotent - it is okay to do the same PUT twice
> without bad stuff happening.

Within the context of the rest of that section, it makes more sense;
GET should be the only method that should be used to dereference a URI.

Personally, I think this point (I note that it isn't an axiom) should
not relate to the existence of other dereferencing methods, but to the
information space that is formed by GET.

The concern about other methods creating other information spaces not
identifiable with URIs is valid.  I've always wondered why OPTIONS
exists, for example, as it creates a parallel non URI identifiable
information space (unless Content-Location can be used?).  Perhaps
there were practical considerations, I don't know (being only a
relative newbie to Web architecture).

M-GET from RFC 2774 is another interesting case.  It is a method used to
dereference URIs, but I don't believe it goes against Tim's
recommendation as it is defined to operate on the same information space
built by GET.

> >From Mark Baker in private mail:
> "Idempotent just means that 'the side-effects of N > 0 identical requests is
> the same as for a single request'.  So if you didn't know whether PUT worked
> or not, you could do it again without fear."

.. modulo minding the lost update problem;

http://www.w3.org/1999/04/Editing/

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Thursday, 10 January 2002 20:20:35 UTC