* Zbigniew Lukasiak <[EMAIL PROTECTED]> [2008-01-22 08:35]: > On Jan 22, 2008 1:30 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> [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/> _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
