相关文章推荐
忧郁的薯片  ·  如何编写一个 Vue JS ...·  11 月前    · 
飞翔的遥控器  ·  WPF 关于 ComboBox ...·  1 年前    · 
风度翩翩的西装  ·  EF Core ...·  1 年前    · 
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.

404 errors are somewhat ambiguous for differentiating a bad URI versus entity not found. A new standard code is needed to disambiguate 404s. Breakskater Mar 7, 2019 at 16:45 This article ( kinsta.com/blog/http-status-codes ) describes an HTTP code grouping of "200s: Codes returned when browser request was received, understood, and processed by the server." vs "400s: Codes indicating that there was a problem with the request". Based on that, to me it would seem that if the logic is successfully querying a database for something by ID and nothing was found for that ID there wasn't a "problem with the request", it was more "the successful query of data found no data matching the criteria", HTTP 204 seems more appropriate than HTTP 404. StackOverflowUser Jul 1, 2021 at 5:52 @hsnslh 204 is wrong as it is ment to use if the content currently displayed has not changed. Only some header fields might vary. I also used this status code as a lack of 404 differentiation. Overall, I would say the most important thing is to document which status code you use for each scenario. Also an apropriate error massage is always helpful. FishingIsLife Oct 11, 2021 at 13:04

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.

What if I want to update foo object with id=1 and there is no foo in the database with this id? valijon Nov 15, 2018 at 10:03 In this scenario, you have a concurrency problem to fix: if you retrieved an object with id=1 and it no longer exists when you try to update it, some other thread or process ignored your lock (or you didn't set one) and deleted it. That's not good. Alternatively, if you're trying to update object id=n (where n is provided to you) without first checking it exists, you're missing a validation step in your update logic, which is also not good. Eight-Bit Guru Nov 15, 2018 at 14:35

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

"Item not found" is usually not a success, so I don't think a 2xx status code is appropriate. ThiefMaster Aug 17, 2020 at 20:35 If you read carefully, will notice that it was taken from oficial content. Go access the url and remove this down vote pls Ricardo Gellman Sep 21, 2020 at 16:59 I don't see anything on the MDN page that backs your claim that this is an appropriate response. I understand 204 as a response code for an action that does not need content, like having deleted something. Trying to get data for a user that does not exist is not a success. ThiefMaster Sep 23, 2020 at 19:42 I like this answer. I believe the documentation in the link backs it up as well. In my scenario I have a dropdown list that pulls from one of two tables based on a toggle switch. If the initially selected value isn't available in the list after toggling, a 204 error code sounds like a solid way to indicate the condition. Mideus Oct 22, 2020 at 16:06

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.

By saying "additional parameter" do you mean request header field? Otherwise I wouldn't recommend using 412. "The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server." oferei Sep 21, 2015 at 11:45

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.

    No, 204 is not correct here at all. 204 simply means that the response has no content, e.g. because it was a request to delete something or trigger some action where there's no need to send anything but "it was successful" back to the client. – ThiefMaster Jan 8 at 13:18 * {@code 422 Unprocessable Entity}. * @see <a href="https://tools.ietf.org/html/rfc4918#section-11.2">WebDAV</a> UNPROCESSABLE_ENTITY(422, "Unprocessable Entity") While this code may answer the question, providing additional context regarding why and/or how this code answers the question improves its long-term value. How to Answer. Kind Regards. – Elletlar Nov 12, 2020 at 11:09 I strongly prefer something other than 422 for the OP's described use case, as 422 is typically implemented for malformed body/form/query/<input> parameters and such. As an example, the Python web framework FastAPI uses 422 errors canonically, in my opinion. – Jason R Stevens CFA Dec 6, 2022 at 17:03 That implies the user will see just the error code and no nice error page. This is not the case though - in any well-made web application, error pages are user-friendly and while they may show the code somewhere, what matters to regular users is the text there. – ThiefMaster Dec 22, 2020 at 12:37