What is the correct HTTP status code for a child entity that is not found?

Question

Say I've got a resource

/Products/123

And each Product has an associated Supplier entity in the back end database. POST and PUT requests must specify a supplier ID, which is then used to fetch a Supplier entity from the database.

What should be returned if a user issues a PUT /Products/123, which is found, but includes a bad Supplier ID, which is not?

404 Not Found with a message specifying which resource wasn't found?

409 Conflict?

Answer 1

The 404 status code may not be right choice because the resource that has not been found is not the target of your request:

6.5.4. 404 Not Found

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.

The 409 status code might be suitable for this situation, but is not be the best choice (I wouldn't define this situation as a conflict):

6.5.8. 409 Conflict

The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict. [..]

I would go for 422 status code with a clear description in the response payload:

11.2. 422 Unprocessable Entity

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

If 422 doesn't work for you, use the generic 400:

6.5.1. 400 Bad Request

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

---

The following diagram (extracted from this page) is pretty insightful when it comes to picking the most suitable 4xx status code:

Answer 2

I don't believe that there is a correct answer for this question (unless some REST purist can shed some light) but we currently use (or abuse...) HTTP 400 (Bad Request) with an additional HTTP Header explaining the error (i.e. X-Error: Invalid supplier ID). However a HTTP 422 would also be a good alternative. Statuses 404 or 409 would be confusing since there is no clear way to specify that the response is about a sub-resource.