Say I\'ve got a resource
/Products/123
And each Product
has an associated Supplier
entity in the back end databas
Hello I would use the 404 as mentioned prior:
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.
Because the product that you are looking for exists, but the Supplier ID not, so basically is like we are looking for you in a different city, you exist but not in that city, so we will say, hey we did not found you.
I believe that supplier and product they have a relationship and it is a hard relationship, that a product can not exist if you don't have a supplier for that product, so that means you can not update a product if you don't know it is supplier.
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. A404
status code does not indicate whether this lack of representation is temporary or permanent; the410
(Gone) status code is preferred over404
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 a415
(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a400
(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.
The following diagram (extracted from this page) is pretty insightful when it comes to picking the most suitable 4xx
status code:
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.