HTTP code to return for unsupported PATCH

Question

I am implementing a PATCH method on a dropwizard REST resource. Currently only a subset of the properties of the resource an be patched. And currently only the replace operation can be fulfilled.

Which HTTP code should I return if I see a PATCH request for a property/path that is not suppported? And what should I return if the unsupported add or remove operations are requested?

Answer 1

Which HTTP code should I return if I see a PATCH request for a property/path that is not suppported?

In this situation, the server should return 405 to indicate that a HTTP method is not supported by the target resource. Besides the status code, the server must return an Allow header listing the supported methods for that resource:

6.5.5. 405 Method Not Allowed

The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.

---

And what should I return if the unsupported add or remove operations are requested?

I assume you mean add and remove operations from JSON Patch, a JSON document that describes a sequence of operations to apply to a JSON document and is suitable to be used with the PATCH HTTP method.

So have a look a the error handling section of the RFC 5789, the document that defines the PATCH HTTP method.

The situation described in your question is, in fact, an entity that cannot be processed by the server due to semantic reasons. So 422 is a reasonable choice, according to the RFC 5789:

Unprocessable request: Can be specified with a 422 (Unprocessable Entity) response 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. [...]

Also keep in mind the following recommendation from the same document:

The entity body of error responses SHOULD contain enough information to communicate the nature of the error to the client. The content- type of the response entity can vary across implementations.

The RFC 7807 defines document formats that can be used for reporting problems in HTTP APIs.