An Introduction to the HTTP PATCH Method
HyperText Transfer Protocol (HTTP) specifies the way in which clients and servers on the World Wide Web communicate with each other.
This communication is accomplished through the use of HTTP request methods.
For example, the most commonly used method, GET, is used by a client to request that a web server provide a specified resource.
This is the method that your web browser sends when requesting that a web page begin loading a particular page. GET is not the only HTTP method provided by the HTTP protocol, however.
Another, more specialized HTTP method is PATCH.
Patch Example
Consider a resource, employee. The JSON representation of an example might look like this:
{
"name":"John Doe", "department":"sales", "salary":65500
}If the salary field of this employee record needed updating, the PUT method could be used to replace the employee, but this would be wasteful.
{
"name":"John Doe", "department":"sales", "salary":70000
}The PATCH command could be used instead to send only the new salary:
{
"salary":70000
}In the trivial example presented here, the savings from using PATCH is obviously very small, but for a more complex case, where objects contain much more data, the savings could be very material.
Patch vs PUT
The HTTP PATCH method can be used when a resource needs to be updated. This method is especially useful if a resource is large and the changes being made are small.
The HTTP PUT method can be used to create a new resource or to replace an existing resource with a new resource. However, the entire resource must be replaced.
There are some cautions to keep in mind when choosing to use PATCH over PUT. PUT is guaranteed to be idempotent. PATCH is not. Likewise, PUT is considered “safe” in the sense of RFC 2616, while PATCH is not.
Summary
The PATCH method could return a number of different status codes. For a successful PATCH, common status codes would likely be 200 (OK) or 204 (No Content). If the PATCH method was unsuccessful, status codes such as 304 (Not Modified), 400 (Bad Request), or 422 (Unprocessable Entity) may be seen.
Many applications have potential benefits from the use of the PATCH command and it should certainly be considered when designing the methods a web application will support. Support for PATCH does bring with it more complex than required for support of PUT alone, but the benefits are absolutely worth considering.
