Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
I'm curious what's the most appropriate HTTP status code for an "item does not exist" page.
If the page itself doesn't exist, I'll obviously use 404. However, one of my pages has a
userid
argument (it's an "edit user" page) and in case no user with the given user ID exists I'm displaying an error page, but I'd also like to send a 4xx status header (since "200 OK" doesn't really fit).
I guess 404 would be ok since it's "not found" and not "file not found", but I wonder if there's a better code for this case.
–
–
–
A 404 return code actually means 'resource not found', and applies to any entity for which a request was made but not satisfied. So it works equally-well for pages, subsections of pages, and any item that exists on the page which has a specific request to be rendered.
So 404 is the right code to use in this scenario. Note that it
doesn't
apply to 'server not found', which is a different situation in which a request was issued but not answered at all, as opposed to answered but without the resource requested.
–
–
No Content.” This code means that the server has successfully
processed the request, but is not going to return any content
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
–
–
–
–
That's depending if userid is a resource identifier or additional parameter. If it is then it's ok to return 404 if not you might return other code like
400 (bad request) ‐ indicates a bad request
412 (Precondition Failed) e.g. conflict by performing conditional update
More info in free
InfoQ Explores: REST
book.
–
If the page itself doesn't exist, I'll obviously use 404.
What you said there is a bit confusing but I will have to assume that you're developing an API backend.
The problem is that whoever is consuming the API endpoint may be confused in two ways:
They may think the
404
returned is because the endpoint(resource) wasn't reached, Or
They might think that the item or user being requested wasn't found.
So the trick is, how are they going to know which is the right assumption?
Well, the answer is simple. Always try to attach a body to any errors that you returned from code. Errors that are returned by the server automatically do not have a body. So try to attach a body which you can document so that they can be able to use the content of the body to differentiate between code returned errors and server errors.
But in a nutshell,
404
is the right status to return, but try to attach a body to it indicating why
404
was returned.
An example could be:
// For illustration I'm just gonna use C#
Return NotFound(new { errorMessage: "Item requested was not found" });
Here, NotFound
returns a 404 statuscode and the parameter is an object like
{ errorMessage: "some reason for the error"}
. This way, you can always check if your error returned a body, and the you know it's returned from your code. Otherwise, the resource(link) wasn't found.
404
status code automatically appears when the requested API is
unavailable. Links that lead to a 404 page are often called broken
or dead links and can be subject to link rot.
204 Status Code:
204
status code should when item not found which means your request
processed successfully and the content not found.
–
* {@code 422 Unprocessable Entity}.
* @see <a href="https://tools.ietf.org/html/rfc4918#section-11.2">WebDAV</a>
UNPROCESSABLE_ENTITY(422, "Unprocessable Entity")
–
–
–