The HTTP PATCH request method applies partial modifications to a resource.
The HTTP PUT
method is already defined to overwrite a resource with a complete new body, and for the POST
method there is no standard way to discover patch format support. Unlike PUT
, but like POST
, PATCH
is not idempotent, meaning successive identical patch requests will have different effects.
To find out whether a server supports PATCH
, a server can advertise its support by adding it to the list in the Allow
or Access-Control-Allow-Methods
(for CORS) response headers.
Another (implicit) indication that PATCH is allowed, is the presence of the Accept-Patch
header, which specifies the patch document formats accepted by the server.
Request has body | Yes |
---|---|
Successful response has body | No |
Safe | No |
Idempotent | No |
Cacheable | No |
Allowed in HTML forms | No |
Syntax
PATCH /file.txt HTTP/1.1
Example
Request
PATCH /file.txt HTTP/1.1 Host: www.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100 [description of changes]
Response
A successful response is indicated with a 204
response code, because the response does not carry a message body.
HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f"
Specifications
Specification | Title |
---|---|
RFC 5789: PATCH | PATCH Method for HTTP |
See also
204
Allow
,Access-Control-Allow-Methods
Accept-Patch
– specifies the patch document formats accepted by the server.