My preference for updating data across the web is to send only the information that is different, and the service ensures everything else remains the same. Put doesn't quite cut it in this case (technically, it's supposed to completely replace a resource).
Are there any advantages for declaring Patch to be not idempotent? I'm assuming it allows appending to a single resource?
A PATCH request can be issued in such a way as to be
idempotent, which also helps prevent bad outcomes [...]
Clients using this kind of patch application SHOULD use
a conditional request [...] For example, the client
can use a strong ETag [RFC2616] in an If-Match header on
the PATCH request.
At the protocol level, there are no guarantees. At the application level, you can fake it (in the non-mathematical sense) by checking sentinels/guids or testing for applicability. This provides safety, but requires code.
But that's not really idempotence. I don't see any way that the IETF could specify a generic idempotent patch mechanism, or declare an arbitrary mechanism to be idempotent.
EDIT: it looks like you want idempotence a la SQL UPDATE. That seems eminently doable in the application layer. Specifying it in an RFC would be inadequately generic for a whole new HTTP verb, I think.
I personally agree with the parent. PATCH should be idempotent; overwriting values with new values is idempotent and that should be written into the spec rather than avoiding it in favour of things like writing logs (which IMHO should be a POST).
You can write an idempotent PATCH mechanism. If that's what you want, you can do it. You control the server, so you can restrict the accepted patch formats to idempotent ones.
Adding an HTTP verb doesn't make patching magically happen. Someone has to write the logic, either you or your framework authors. Obviously there will be different mechanisms and some will be effectively idempotent. Again, not in the mathematical or functional programming sense, but in the colloquial DBA sense, at least.
Limiting HTTP PATCH at the protocol level would be a huge mistake, I think.
None of this should be construed to mean that I see a clear need for a new HTTP verb, though.
There are also cases where patch formats do not need to operate from
a known base-point (e.g., appending text lines to log files, or non-
colliding rows to database tables) [...]Personally, I think Post does a good enough job for that. I know it's technically supposed to create a sub-resource, but it seems to work for appending to the same resource just as well.
I'm a little uncertain of the case for using Patch to append rows to a database. Surely that's a case where Post does a better job?
On a more personal level, I'm of the opinion that Post can append to an existing resource, without adding a new resource.
Allowing for this practicality in the spec would allow Patch to be only idempotent.
The point is, the ‘patch’ itself is a transformation defined by a 2-tuple of the old value and the delta (whereas a ‘put’ would be defined as the 2-tuple of the old value and the new value). Because the old value is referenced by the request URI (which is mutable), simply specifying the delta itself is not idempotent. Of course, following the RFC's advice and adding the ETag means you're specifying both the delta and the old value, which makes the operation idempotent.