Using REST principles, 404 seems to be used to indicate that an entity does not exist. However, how can clients distinguish this case from hitting an incorrect endpoint alt
you came to the right endpoint, but that entity doesn't exist
If there is no resource identified by the URL, how could it be the right endpoint? The only possible scenario I could think of is that the entity has been deleted, in which case 410 Gone is the correct response.
Remember that if you are following RESTful principles then the URL should have been provided by the server and if so, why is the server handing out invalid URLs?
I believe the determination of the correct endpoint is the sole responsibility of the REST client. (Of course, an endpoint resolution service could be easily implemented.) A 404 error just means that this particular endpoint doesn't host that particular entity.
Nothing in RESTful design requires a server to know if a client is interacting with the "correct" host.
Assuming a framework laid out like this:
/ -- root
|____+
/object
|____+
/members
|____+
/attributes
|____+
/attribute_1
/attribute_2
...
/attribute_n
If you mean that you want to be able to distinguish between someone hitting
/object/members/attributes/incorrect_attribute
(a 404 using all the right commands, but attempting to retrieve a non-existent resource)
and someone hitting /object/members/big-bird
(Assuming that members
cannot be a valid endpoint on its own
[and that /object/members/attributes
is not a valid endpoint either])
then I believe that you could return either a 501 error (not implemented) or a 403 error (Forbidden) depending on where you wanted to place the blame. (Alternately, 418 (I'm a teapot) is also valid here).
EDIT:
Finally, if attribute_n
used to exist and no longer does, you could respond with a 410 (resource gone).
See: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
According to Wikipedia HTTP status codes page
400 Bad Request
The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing)
I personally stick to this - you, the client, made a bad request, and you should feel bad about this =)