Mark Baker: | On 6/19/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote: | > You are right, I should have written "PUT is defined to be | idempotent | > (by the spec), POST is not - which means POST can or cannot be | > idempotent". Seems a little like splitting hairs, but OK. | | Not quite. POST is defined to be non-idempotent, i.e. if you see an | HTTP message with a POST request method, then that message is a | non-idempotent message. What any particular receiving implementation | *does* with such a message - idempotent or not - is an entirely | separate issue.
Jan Algermissen: | Actually, I'd say that every single invokation of POST is | significant from a client's POV and it explicitly expects | multiple POSTs to have distinct effects, or? | | IMO, POST *is* in fact non-idempotent...always. Per definition. I find it hard to find this in RFC2616, and it seems impossible as well. RFC2616: "Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property." So PUT is idempotent, and POST not necessarily so, but where does it say that POST messages are _always_ non-idempotent? Seems impossible too. Presumably a non-idempotent method has the property that "the side-effects of N > 0 identical requests is NOT the same as for a single request" So if I POST twice, and get 500 with a body "Credit expired" twice, that's an idempotent message, right? In fact, if it get that response once, my expectation would be to get it the next time as well. We'd have to re-interpret RFC2616 as really saying "for POST the side-effects of N > 0 identical succesfull requests SHOULD NOT be the same as for a single request", but this seems nonsensical to me. Whether a message is idempotent or not is up to the business logic behind it, and POST is telling the client it may not count on the message being idempotent, and must act accordingly (not just re-POST after failure). POST - IMO - isn't telling the client there are indeed such side-effects for N > 0 messages to be expected. I've always read RFC2616 as saying PUT is always idempotent, and with POST the client cannot count on it being idempotent or not, but correct me if I'm wrong. It also seems to leave an empty slot. With PUT, the client is supposed to create the URI, with POST, the server. So if I have some logic where I want the server to create the URI (who trusts those darn clients anyway!), and the logic is idempotent, what do I do? RFC 2616: "The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity ... In contrast, the URI in a PUT request identifies the entity enclosed with the request". I can see how that leads to PUT being idempotent, but I cannot see why this would make POST necessarily non-idempotent. Marc de Graauw www.marcdegraauw.com
