2.2. Error Handling
2.2. Error Handling
There are several known conditions under which a PATCH request can fail.
Malformed patch document: When the server determines that the patch document provided by the client is not properly formatted, it SHOULD return a 400 (Bad Request) response. The definition of badly formatted depends on the patch document chosen.
Unsupported patch document: Can be specified using a 415 (Unsupported Media Type) response when the client sends a patch document format that the server does not support for the resource identified by the Request-URI. Such a response SHOULD include an Accept-Patch response header as described in Section 3.1 to notify the client what patch document media types are supported.
Unprocessable request: Can be specified with a 422 (Unprocessable Entity) response ([RFC4918], Section 11.2) when the server understands the patch document and the syntax of the patch document appears to be valid, but the server is incapable of processing the request. This might include attempts to modify a resource in a way that would cause the resource to become invalid; for instance, a modification to a well-formed XML document that would cause it to no longer be well-formed. There may also be more specific errors like "Conflicting State" as mentioned above. In such cases, the server MAY include error information in the response body so that the user can determine what is wrong with the patch request.
Resource not found: If the resource to which the client is attempting to apply the patch does not exist and the server does not support creating new resources with PATCH, the server returns a 404 (Not Found) status code.
Conflicting state: If the request is properly formed and the server supports the media type used in the patch document, but the server is unable to apply the patch because the state of the resource conflicts with the patch or the patch will create a conflict (e.g., a patch that attempts to add a conflicting field, or a conditional request that fails), the server returns a 409 (Conflict) status code. The server SHOULD include enough information in the response body for the client to recognize the source of the conflict.
Conflicting modification: If the request is properly formed and the server supports the media type, but the patch cannot be applied to the resource because the resource has changed from the expected state (e.g., the conditional request failed, a strong ETag does not match the current resource), the server returns a 412 (Precondition Failed) status code.
Concurrent modification: Simultaneous requests to modify a resource with PATCH can have unpredictable results if the patch formats being used require the client to work from an underlying base document. Thus, a PATCH request can fail if concurrent updates cause a conflict. All such concurrent modification risks apply to any interaction where multiple parties make changes to the same resource. The PATCH method does not introduce any unique risks, but is worth highlighting in this section.
Note: For all responses, the server may include error information in the response body so that the client can determine what went wrong or what to do next.