对于“未找到项目”最合适的 HTTP 状态代码是什么？错误页面
我很好奇“项目不存在”页面最合适的 HTTP 状态代码是什么。
如果页面本身不存在，我显然会使用 404。但是，我的其中一个页面有一个 userid 参数（它是一个“编辑用户”页面），以防万一没有给定的用户用户 ID 存在 我正在显示错误页面，但我还想发送 4xx 状态标头（因为“200 OK”并不真正适合）。
我想 404 应该没问题，因为它是“未找到”而不是“文件未找到”，但我想知道对于这种情况是否有更好的代码。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
过于聪明地处理晦涩难懂的 HTTP 错误代码并不是一个好主意。浏览器有时会以无益的方式做出反应，从而使情况变得混乱。坚持使用 404。
Getting overly clever with obscure-er HTTP error codes is a bad idea. Browsers sometimes react in unhelpful ways that obfuscate the situation. Stick with 404.
404 返回代码实际上意味着“找不到资源”，适用于发出请求但未得到满足的任何实体。因此，它对于页面、页面的子部分以及页面上存在的任何具有要呈现的特定请求的项目同样有效。
因此 404 是在这种情况下使用的正确代码。请注意，它不适用于“找不到服务器”，这是一种不同的情况，即发出请求但根本没有得到答复，而不是得到答复但没有请求的资源。
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.
204：https:// /developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
204:https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
404就好了。 来自 RFC9110 的 HTTP 状态代码定义
404 is just fine. HTTP Status Code Definitions from RFC9110
这取决于 userid 是资源标识符还是附加参数。如果是，则可以返回 404，如果不是，您可能会返回其他代码，例如
400（错误请求） - 表示错误请求或
412（先决条件失败）例如执行条件更新会发生冲突免费提供更多信息InfoQ 探索：REST 书。
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 requestor
412 (Precondition Failed) e.g. conflict by performing conditional updateMore info in free InfoQ Explores: REST book.
当未找到该项目时，
204是适当的解决方案，因为404状态代码甚至会抛出未创建 API。404 状态代码：
204 状态代码：
204is the appropriate solution when the item is not found because the404status code will throw even uncreated APIs.404 Status Code:
204 Status Code:
你所说的有点令人困惑，但我不得不假设你正在开发一个 API 后端。
问题是，使用 API 端点的人可能会在两种方面感到困惑：
所以关键是，他们如何知道哪个是正确的假设？
嗯，答案很简单。始终尝试将正文附加到从代码返回的任何错误。服务器自动返回的错误没有正文。因此，请尝试附加一个可以记录的正文，以便他们能够使用正文的内容来区分代码返回的错误和服务器错误。
但简而言之，404 是返回的正确状态，但请尝试在其上附加一个正文，以表明返回 404 的原因。
例如：
这里，
NotFound返回 404 状态代码，参数是一个对象，例如{ errorMessage:“错误的原因”}。这样，您可以随时检查错误是否返回正文，并且您知道它是从代码返回的。否则，找不到资源（链接）。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:
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:
Here,
NotFoundreturns 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.前面的答案缺乏细微差别，但需要大量阅读才能理解其中的差异。
经验法则：
（例如，查询用户的 ID，并且您知道该 ID 应该存在）
（例如，按出生日期搜索用户，而碰巧没有用户拥有此出生日期。这不是一个错误，空结果只是一种可能的结果——并且只会在前端显示一个空结果表）
204 对于现代 REST API 来说非常好......但是请确保您的前端知道告诉200和204之间的区别如果相关的话！
在您的情况下，404 似乎更好，因为它是一个页面（而不是端点），并且尝试访问不存在的用户应该会让应用程序感到惊讶。
请注意，在现代，大多数后端都能够生成一个“404”页面，当找不到该项目时，该页面会显示一条漂亮的消息和其他有用的内容。因此，喜欢的人会配置他们的后端，以便为用户提供一个更具体的“未找到”页面。换句话说，当用户不存在时，
UsersURL 不会生成默认的、漂亮的 404 页面，而是返回该页面的替代版本，显示类似“此用户”的漂亮消息不存在”。The previous answers lack nuance and yet require a lot of reading to understand the differences.
Rule of thumb:
(e.g. querying a user on its ID and you know the ID is supposed to exist)
(e.g. searching users by date of birth and it just so happens that no user has this date of birth. That's not an error, an empty result is just one possible result -- and will just display an empty results table in the frontend)
204 is very nice for modern REST APIs ...But make sure that your frontend knows to tell the difference between 200 and 204 if that's relevant!
In your case it seems like 404 is better as it's a page (not an endpoint) and trying to access a non-existing user is supposed to make the application raise an eyebrow.
Note that in the modern age, most backends are able to generate a "404" page that displays a pretty message and other useful things when the item is not found. As a result, fancy people would configure their backend so that there is an even more specific "not found" page for users. In other words, the
UsersURL would not generate the default, pretty 404 page when the user does not exist but instead return an alternative version of that page, showing a pretty message along the lines of "this user does not exist".由于它是面向用户的页面，因此始终使用
404。这是人们通常知道的唯一代码。对于 api 请求，请使用 400 和错误消息“不存在这样的用户”或类似的内容。
Since it's a user-facing page always use
404. It's the only code people know usually.For the api request, use 400 with the error message "No such user exists" or something along those lines.