PATCHing your HTTP API for fun and profit

Providing some sort of support for patching resources in HTTP APIs is a relatively common goal. In this conversation with Mike Amundsen we talk about what matters when it comes to supporting PATCH operations in HTTP APIs (it's all about the media types and not about the HTTP method), and how much sense it makes to support generic patch operations.
First of all, for many APIs generic patch support probably is not a great design choice. Instead, think of the interactions that are meaningful for what the API is representing, and then support those interactions.
If you do need/want support for patch operations, then the most important part of that is to design a format for representing patch requests. For JSON, there are two standardized formats to choose from, standardized in RFCs 6902 and 7386. Whether you design you API to use the HTTP PATCH or POST method does not make such a big difference, but it's good to be consistent across APIs if you have various APIs supporting patch operations.

[vivekm]

11:10 there is a mistake. Alternative for Patch is not Post. Its PUT. Post is for creating a new resource.