Although the spec makes stronger assertions about its semantics than this, namely that the body of a PUT is supposed to a full replacement for the resource at the URL in question.
However I don't think any clients or middleware take advantage of this or would reliably be able to take any useful advantage of this.
Whereas idempotence is something which client and middleware can usefully take advantage of - eg a browser can safely re-try an idempotent request whereas it can't safely retry a general POST.
Allowing PUT to be used for requests which are idempotent but not technically full replacement updates (eg partial updates) would allow middleware to know that they're safe to repeat.
By constraining the use of PUT to 'full replacement' updates, you deny people a useful way to signal idempotence for other more general kinds of idempotent updates.
http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-...
"PATCH is neither safe or idempotent as defined by [RFC2616] Section 9.1."
The only semantics it has seems to be "change this resource in some way". Sometimes such a change might be idempotent, sometimes not, and the PATCH method provides no way of communicating this.
Personally I see little advantage from adding a PATCH method. Its semantics, as far as any generalised client software or middleware are concerned, seems the safe as POST.
Really the question which this raises is: for what reasons are new REST methods justified?
I think Fielding et al are vague on this topic, and I think the vagueness shows in HTTP (and in proposed extensions like PATCH)
Personally I think new methods should only be justified where they have generalised semantics which can be exploited by middleware (or middleware-like layers in client software) and where no existing method is available to express these semantics. Terms like 'safe' and 'idempotent' are relevant and useful properties to consider at this level.
The data-level semantics (like 'applies a diff to' or 'does something approximately like a full update to') aren't really relevant when it comes to request methods, unless they are properties which it's genuinely useful for generic middleware to know about.
I say this because hypertext and standardised hypertext media types and relations are already great at helping people discover available operations, together with their data/domain-level semantics, without the need for any new request methods.
I believe that PATCH was created because people couldn't come to a consensus on whether PUT was required to replace the whole entity or whether it was allowed to have patch-like abilities.
It is hand-wavey isn't it. The whole REST concept smells of post-hoc generalisation based on just one significant example, HTTP, and as such there seems to be a lot of confused but zealous hermeneutics involved in determining the One True RESTful Way To Do HTTP both from the HTTP RFCs and Fielding's other writings (which can be rather pompous and/or opaque).
Instead, I'd like if people went back to first principles and thought hard about what actual value certain kinds of semantics have which justify (or don't justify) making them part of the protocol, as opposed to just standardising the semantics as part of some media type or other.
Idempotence, to me, seems like something which is genuinely useful and justifies itself as part of a transfer protocol, so I'd like to see HTTP take a clear and useful stance on it.