PATCH (HTTP)

HTTP
Persistence Compression HTTPS QUIC
Request methods
OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT PATCH
Header fields
Cookie ETag Location HTTP referer DNT X-Forwarded-For
Response status codes
301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found 451 Unavailable for Legal Reasons
Security access control methods
Basic access authentication Digest access authentication
Security vulnerabilities
HTTP header injection HTTP request smuggling HTTP response splitting HTTP parameter pollution
v t e

In computing, the PATCH method is a

The POST method can be used for sending partial updates to a resource. The main difference between the POST and PATCH methods is that the POST method can be used only when it is written to support the applications or the applications support its semantics whereas the PATCH method can be used in a generic way and does not require application support. If the outcome of using the PATCH method is not known then the POST method is preferred.[1]^[6]

The PATCH method is

A cached PATCH response is considered stale. It can only be used for the GET and HEAD requests that may follow the PATCH request.[1]

The entity headers in the PATCH document are only applicable to the PATCH document and cannot be applied to the requested resource.^[1]

There is no standard format for the PATCH document and it is different for different types of resources. The server has to check whether the PATCH document received is appropriate for the requested resource.^[1]

A JSON Patch document would look like

[
  { "op": "add", "path": "/count", "value": 1 }
]

"op" represents the operation performed on the resource. "path" represents the resource being modified. "value" represents the amount being added to the existing resource.^[7] Before applying the changes in the PATCH document, the server has to check whether the PATCH document received is appropriate for the requested resource. If the PATCH request succeeds then it returns a 204 response.^[8]

A XML PATCH document would look like

<add sel="doc/user[@email='[email protected]']" type="@address">
ABC Road
</add>

The element <user> is located using the 'email' attribute. A new attribute 'address' with the value "ABC Road" is added to the <user> element.^[9]

A simple PATCH request example

  PATCH /example.txt HTTP/1.1
  Host: www.example.com
  Content-Type: application/example
  If-Match: "c0b42b66e"
  Content-Length: 120
  
  [Changes: the patch document containing all the changes that need to be made on the resource example.txt]

Successful PATCH response to existing text file:

  HTTP/1.1 204 No Content
  Content-Location: /example.txt
  ETag: "dd541480"

The response 204 means that the request was processed successfully.^[10]

Using the

The PATCH method is not "safe" in the sense of RFC 2616: it may modify resources, not necessarily limited to those mentioned in the

The PATCH method is not idempotent. It can be made idempotent by using a conditional request.^[1] When a client makes a conditional request to a resource, the request succeeds only if the resource has not been updated since the client last accessed that resource. This also helps in preventing corruption of the resource since some updates to a resource can only be performed starting from a certain base point.^[1]

A PATCH request can fail if any of the following errors occur:

The server returns a 400 (Bad request) response if the PATCH document is not formatted as required.^[1]

The server returns a 415 (Unsupported Media Type) response with an Accept-Patch response header containing supported media types when the client sends a patch document in a format not implemented by the server. This informs the client that the PATCH document sent by the client cannot be applied to the requested resource.^[1]

The server returns a 422 (Unprocessable Entity) response when the server understands the PATCH document but is unable to modify the requested resource either because it causes the resource to become invalid or it results in some other error state.^[1]

The server returns a 404 (Not Found) response when the PATCH document cannot be applied to a non-existent resource.^[1]

The server returns a 409 (Conflict) response when the server cannot apply a patch for the current state of the resource.^[1]

The server returns a 412 (Precondition Failed) response when the precondition supplied by the client using the If-Match or If-Unmodified-Since header fails. If no precondition is supplied and there is a conflicting modification then the server returns a 409 (Conflict) response.^[1]

The server returns a 409 (Conflict) response if the PATCH requests to a certain resource need to be applied in a certain order and the server is not able to handle concurrent PATCH requests.^[1]

The PATCH request needs to use mechanisms such as conditional requests using Etags and the If-Match request header to ensure that data is not corrupted while patching.^[1] In case of a failure of a PATCH request or failure of the channel or a timeout, the client can use a GET request to check the state of the resource.^[1] The server has to ensure that malicious clients do not use the PATCH method for consuming excessive server resources.^[1]