- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 28 Feb 2012 10:23:51 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mike Kelly <mikekelly321@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 28 February 2012 08:49, Julian Reschke <julian.reschke@gmx.de> wrote: >> A PUT is by definition idempotent. A PATCH, like POST, is only >> idempotent under (secret, non-obvious) conditions. > > That is true, but I'm not sure that is a problem when the conditions are > well understood and documented. That's the part that needs to be clearer. Because I'm not certain that I can look at a given PATCH (or POST) request and make a determination about idempotence. The problem is that RFC 5789 categorically denies that PATCH is idempotent (then goes on to qualify as you cited previously.) Is it always true that a PATCH request with an If-Match header containing a strong ETag is idempotent? I think that it is as long as the contract is observed (i.e. the server pays attention to the If-Match; the ETag really is strong). I don't think that any of the other conditional headers can be used to make a statement of the same certitude. Of course, there are plenty of requests that could be non-idempotent, but - if you understand the context - are actually idempotent. That's the point of contention: is it desirable that this property be observable (thanks Carsten)? I don't see a strong reason to. (What I think you saw as motivation to do so, was just an attempt at clarifying a technical point.) I tend to think that if this is important, you need to restructure your resources (my original point). --Martin
Received on Tuesday, 28 February 2012 18:24:24 UTC