This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

RFC 5789: PATCH Method for HTTP

Stefan Tilkov,

After a long, long time, the HTTP PATCH verb has become an official standard: IETF RFC 5789. From the abstract:

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.

That's pretty great news, even though it will probably take some time before you can actually gain much of a benefit from it. Until now, there were two options of dealing with resource creation (and update, for that matter):

  • Use a POST to create a new resource when you want the server to determine the URI of the new resource
  • Use a PUT to do a full update of a resource (or create if it's not there already)

Sometimes, though, what you're looking for is a partial update. You have a bunch of different choices: You can design overlapping resources so that one of them reflects the part you're interested in, and do a PUT on that; or you can use POST, which is so unrestricted it can essentially mean anything.

With PATCH, you have a standardized protocol-level verb that expresses the intent of a partial update. That's nice, but its success depends on two factors:

  • The availability of standardized patch formats that can be re-used independently of the application
  • The support for the verb in terms of infrastructure, specifically intermediaries and programming toolkits

In any case, I will definitely start advocating its use for the purpose it's been intended to support, even if this means going with home-grown patch formats for some time: It's still better than POST, and using some sort of x-http-method-override-style workaround should work nicely if needed.

Kudos to James Snell for investing the time and energy to take this up.

On March 24, 2010 10:13 AM, Jörg Plewe said:

In a couple of years there will be zillions of verbs and http and its applications will be as complex and difficult as the complexity requires. So the charme of http being easy to use (bc. it’s simple/primitive) will get lost. Does http kill itself?

On March 24, 2010 10:19 AM, Stefan Tilkov said:

Hah, absurd as usual :-) Given that it’s taken something like 10 years to get PATCH in, I’m confident the Web will be able to handle the next few decades quite easily.

On April 3, 2010 2:35 AM, Benjamin Carlyle Author Profile Page said:

It’s a shame that there is no idempotent patch, though. It’s main use case of modifying enclosed sub-entities without needing a special link relation from (say) and invoice to it’s items seems unlikely to benefit from this specification.

On September 13, 2010 10:40 AM, Mutuelle Santé said:

I think in the coming years and with the fast growing high tech,http will loose his identity.So sad as it was very simple and easy to manage.

On February 25, 2011 9:36 PM, Articles said:

Isn’t the current HTTP 1.1 set of verbs too limited for real world RESTing? I beleive sing PUT with ETag headers is a better approach to modifying a resource then trying to put together some new verb with unknown results.