Conflicting required response codes on POST request with unsupported client id creation and wrong type?

1

Hello!

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:

  1. An ID, even though client-generated IDs are not supported by the server.
  2. 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 409 Conflict.

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?

2

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 403 or 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.

3

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 403 or 409?