In the spec for 1.1, under “9.1 - Creating Resources”, it is stated that:
A server MUST return
403 Forbidden in response to an unsupported request to create a resource with a client-generated ID
It is also stated that:
A server MUST return
409 Conflict when processing a
POST request in which the resource object’s
type is not among the type(s) that constitute the collection represented by the endpoint.
It seems these two requirements can conflict with each other, in the case where the POSTed resource object has both of these:
- An ID, even though client-generated IDs are not supported by the server.
- A type that is not part of the collection represented by the endpoint
For this case, the spec says that the server MUST return
403 Forbidden and that the server MUST return
Obviously, there can only be a single HTTP response code. Is this an inconsistency in the spec, or could it be argued that for instance the unsupported type takes precedence over the unsupported ID, an that
409 Conflict should therefore be used?
I think the general section about error handling provides guidance here:
A server MAY choose to stop processing as soon as a problem is encountered, or it MAY continue processing and encounter multiple problems.
If a server choose to stop processing on first error, it may return
409 depending which rule the server validates first.
If the server continues processing and encounter multiple problems, another rule comes into play:
When a server encounters multiple problems for a single request, the most generally applicable HTTP error code SHOULD be used in the response. For instance, 400 Bad Request might be appropriate for multiple 4xx errors or 500 Internal Server Error might be appropriate for multiple 5xx errors.
Thanks @jelhan ! So perhaps
The server MUST return status code X on error Y
is better interpreted as
If the server returns a status code based solely on error Y, then that code MUST be X
And in the case where the server comes across both the error categories mentioned above, and returns error objects for both of them in the same response, then a more appropriate status code might be
400 rather than picking either