[Catalyst] Re: REST - like uri design for CRUD

[Aristotle Pagaltzis]

* Zbigniew Lukasiak <zzbbyy at gmail.com> [2008-01-22 08:35]:
> On Jan 22, 2008 1:30 AM, Aristotle Pagaltzis <pagaltzis at gmx.de> wrote:
> > I don't understand this question. It sounds like you have
> > some confusion about several distinct things and that you
> > don't actually understand what idempotence is. Can you try to
> > explain a bit more what you are trying to ask? Are you just
> > asking why there are more verbs than GET and POST? Are you
> > asking about why it's important to categorise verbs as
> > non-/safe in addition to non-/idempotent? Is it something all
> > together different?
> 
> The first one.  Why you need to split the class of
> non-idempotent operations into three more categories (POST, PUT
> and DELETE).

* Zbigniew Lukasiak <zzbbyy at gmail.com> [2008-01-22 11:10]:
> Just after sending it I have realized that DELETE can be also
> viewed as idempotent since a second call to it does not really
> change the state (even if it can return an error to the
> caller). And that shows another question - perhaps all we need
> is the simple division into safe and non-safe operations?


It seems to me you are still confusing several things.

“Idempotent” means that the request will have the same result if
you make it repeatedly. GET, PUT and DELETE are all idempotent:
no matter how often you repeat them, the resulting resource state
on the server will always be the same. This is important insofar
as if the request times out due to a network problem, say, the
client can simply retry it without any ill effects. This also
means proxies can retry such requests for you. POST is not
idempotent, in contrast.

“Safe” means the client may assume that the server will not do
anything harmful in processing the request, and if the server
does, the client is not responsible for it. GET is safe in
addition to being idempotent: clients may assume that they can
send GET requests and nothing terrible will happen. If you `GET
/all-my-data/delete` and the server deletes all your data, and it
should not have, then it’s the server’s fault, not the client’s.
This makes it possible to write things like search engines and
other web crawlers, f.ex.

Another reason to have separate PUT and DELETE is because without
them, you have to tunnel meaning through the body of POST, which
muddles things. The semantics of POST depend on the URI which is
being posted to, whereas the semantics of PUT are always clear:
the client asserts that the resource state should from now on
correspond to the request body entity. If the server decides to
process a PUT request to a URI, it is always clear what is going
to happen; if the server decides to process a POST request to a
URI, as a client, you have no idea what it will do.

Same reasoning goes for DELETE, and for the PATCH draft currently
being written.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>