PATCH request method
ThePATCH HTTP method applies partial modifications to a resource.
PATCH is somewhat analogous to the "update" concept found inCRUD (in general, HTTP is different thanCRUD, and the two should not be confused).
In comparison withPUT, aPATCH serves as a set of instructions for modifying a resource, whereasPUT represents a complete replacement of the resource.APUT request is alwaysidempotent (repeating the same request multiple times results in the resource remaining in the same state), whereas aPATCH request may not always be idempotent.For instance, if a resource includes an auto-incrementing counter, aPUT request will overwrite the counter (since it replaces the entire resource), but aPATCH request may not.
LikePOST, aPATCH request can potentially have side effects on other resources.
A server can advertise support forPATCH by adding it to the list in theAllow orAccess-Control-Allow-Methods (forCORS) response headers.Another implicit indication thatPATCH is supported is theAccept-Patch header (usually after anOPTIONS request on a resource), which lists the media-types the server is able to understand in aPATCH request for a resource.
| Request has body | Yes |
|---|---|
| Successful response has body | May |
| Safe | No |
| Idempotent | No |
| Cacheable | Only if freshness information is included |
| Allowed inHTML forms | No |
In this article
Syntax
PATCH <request-target>["?"<query>] HTTP/1.1<request-target>Identifies the target resource of the request when combined with the information provided in the
Hostheader.This is an absolute path (e.g.,/path/to/file.html) in requests to an origin server, and an absolute URL in requests to proxies (e.g.,http://www.example.com/path/to/file.html).<query>OptionalAn optional query component preceded by a question-mark
?.Often used to carry identifying information in the form ofkey=valuepairs.
Examples
>Successfully modifying a resource
Assume there is a resource on the server representing a user with a numeric ID of123 in the following format:
{ "firstName": "Example", "LastName": "User", "userId": 123, "signupDate": "2024-09-09T21:48:58Z", "status": "active", "registeredDevice": { "id": 1, "name": "personal", "manufacturer": { "name": "Hardware corp" } }}Instead of sending a JSON object to fully overwrite a resource, aPATCH modifies only specific parts of the resource.This request updates thestatus field:
PATCH /users/123 HTTP/1.1Host: example.comContent-Type: application/jsonContent-Length: 27Authorization: Bearer ABC123{ "status": "suspended"}The interpretation and authentication of thePATCH request depend on the implementation.Success can be indicated by any of thesuccessful response status codes.In this example, a204 No Content is used as there's no need to transmit a body with additional context about the operation.AnETag is provided so the caller can perform aconditional request in future:
HTTP/1.1 204 No ContentContent-Location: /users/123ETag: "e0023aa4f"Specifications
| Specification |
|---|
| RFC 5789> |
Browser compatibility
The browser doesn't use thePATCH method for user-initiated actions, so "browser compatibility" doesn't apply.Developers can set this request method usingfetch().
See also
- HTTP request methods
- HTTP response status codes
- HTTP headers
204Allow,Access-Control-Allow-MethodsheadersAccept-Patch– specifies the patch document formats accepted by the server- JSON Patch Generator