PATCH Method for HTTP
This specification defines a new HTTP 1.1 [1] method PATCH that is
used to apply partial modifications to a HTTP resource. A new method
is necessary to improve interoperability and prevent errors. The PUT
method is already defined to overwrite a resource with a complete new
body, and MUST NOT be reused to do partial changes. Otherwise,
proxies and caches and even clients and servers may get confused as
to the result of the operation.
This is a revival of an expired Internet Draft RFC; it will be very interesting to see how much support this gets. Personally, I’m still undecided; I understand the theoretical value, but I wonder whether the cost of introducing a new verb isn’t prohibitive (which means that PUT or POST would have to be used).
Note that the way this is refactored in this draft, it would actually be very simple to use POST as a fallback alternative. It’s not ideal, but it’s definitely possible.
Seems like a good compromise - this would allow the ”market” to decide which strategy is more appropriate.
POST will always be a viable (and in many circumstances; required) fallback method for PUT, DELETE and other non-idempotent HTTP methods. I still think PATCH has a real value on an read-write web (with emphasis on write), though.
When the payloads get large enough and the client’s changes only involve a minor spelling correction or something similar, a PATCH fits very neatly. What’s exciting is the amounts of cool MIME types you can stuff into a PATCH request, depending on the type of content you’re manipulating. For XML documents, “application/xquery” is a nice match. For plain text documents, “text/x-regex” is a good alternative. For JSON data, application/ecmascript might be a good fit. Et cetera.
Right up there with “never get involved in a land war in Asia” in the list of classic blunders is (or at least should be) “never build a mass market framework around a single notion of ‘entity’”. I feel like extending HTTP before dealing with the coming REST bandwagon is ill-advised. Out of the dust, just maybe, one or two new ideas about what a resource (or a subordinate) is — especially relative to a URL - might affect the future of HTTP. If the need for PATCH is murky now, maybe we should float it after we know the upcoming needs.