什么是“未找到项目”错误页面最合适的 HTTP 状态代码

Posted 2023-02-19

【中文标题】什么是“未找到项目”错误页面最合适的 HTTP 状态代码

【英文标题】：What's the most appropriate HTTP status code for an "item not found" error page

【发布时间】：2021-04-07 08:06:54

【问题描述】：

我很好奇什么是“项目不存在”页面最合适的 HTTP 状态代码。

如果页面本身不存在，我显然会使用 404。但是，我的一个页面有一个 userid 参数（它是一个“编辑用户”页面），以防没有具有给定用户 ID 的用户存在我正在显示一个错误页面，但我还想发送一个 4xx 状态标题（因为“200 OK”并不适合）。

我猜 404 会没问题，因为它是“未找到”而不是“未找到文件”，但我想知道这种情况是否有更好的代码。

【参考方案1】：

如果页面本身不存在，我显然会使用 404。

你所说的有点令人困惑，但我不得不假设你正在开发一个 API 后端。

问题在于，使用 API 端点的人可能会以两种方式感到困惑：

他们可能认为返回的404是因为没有到达端点（资源），或者 他们可能认为未找到所请求的项目或用户。

所以诀窍是，他们如何知道哪个是正确的假设？

嗯，答案很简单。始终尝试将正文附加到您从代码返回的任何错误。服务器自动返回的错误没有正文。因此，请尝试附加一个您可以记录的正文，以便它们可以使用正文的内容来区分代码返回的错误和服务器错误。

但简而言之，404 是返回的正确状态，但请尝试在其上附加一个主体，说明返回 404 的原因。

一个例子可以是：

// For illustration I'm just gonna use C#
Return NotFound(new  errorMessage: "Item requested was not found" );

这里，NotFound 返回一个 404 状态码，参数是一个对象，如 errorMessage: "some reason for the error"。这样，您始终可以检查您的错误是否返回了正文，并且您知道它是从您的代码中返回的。否则，找不到资源（链接）。

【参考方案2】：

由于它是面向用户的页面，请始终使用404。这是人们通常知道的唯一代码。

【讨论】：

这意味着用户只会看到错误代码，而看不到漂亮的错误页面。但情况并非如此 - 在任何制作精良的 Web 应用程序中，错误页面都是用户友好的，虽然它们可能会在某处显示代码，但对普通用户而言重要的是那里的 文本。

【参考方案3】：

/**
* @code 422 Unprocessable Entity.
* @see <a href="https://tools.ietf.org/html/rfc4918#section-11.2">WebDAV</a>
*/
UNPROCESSABLE_ENTITY(422, "Unprocessable Entity")

【讨论】：

虽然此代码可能会回答问题，但提供有关此代码为何和/或如何回答问题的额外上下文可提高其长期价值。 How to Answer。亲切的问候。

【参考方案4】：

204：

没有内容。”此代码表示服务器已成功 处理了请求，但不会返回任何内容

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204

【讨论】：

"Item not found" 通常不会成功，所以我认为 2xx 状态码不合适。

如果你仔细阅读，会发现它取自官方内容。去访问网址并删除这个反对票

我在 MDN 页面上没有看到任何支持您声称这是一个适当响应的内容。我将 204 理解为不需要内容的操作的响应代码，例如删除某些内容。尝试为不存在的用户获取数据并不成功。

我喜欢这个答案。我相信链接中的文档也支持它。在我的场景中，我有一个下拉列表，它基于切换开关从两个表之一中提取。如果切换后最初选择的值在列表中不可用，则 204 错误代码听起来像是指示条件的可靠方法。

【参考方案5】：

这取决于 userid 是资源标识符还是附加参数。如果是，则可以返回 404，否则您可能会返回其他代码，例如

400 (bad request) ‐ indicates a bad request 或412 (Precondition Failed) e.g. conflict by performing conditional update

更多信息请参阅免费的InfoQ Explores: REST book。

【讨论】：

说“附加参数”是指请求头字段吗？否则我不建议使用 412。“412（前提条件失败）状态代码表示在服务器上测试时，请求标头字段中给出的一个或多个条件评估为 false。”

【参考方案6】：

404 返回码实际上表示“找不到资源”，适用于已发出请求但未满足的任何实体。因此，它同样适用于页面、页面的子部分以及页面上存在的任何需要呈现特定请求的项目。

所以 404 是在这种情况下使用的正确代码。请注意，它不适用于“未找到服务器”，这是一种不同的情况，即发出请求但根本没有得到响应，与已响应但没有请求的资源相反。 p>

【讨论】：

如果我想更新 id=1 的 foo 对象，而数据库中没有具有此 id 的 foo 对象怎么办？

在这种情况下，您有一个并发问题需要解决：如果您检索到一个 id=1 的对象并且在您尝试更新它时它不再存在，则其他一些线程或进程忽略了您的锁 (或者你没有设置一个）并删除它。这不好。或者，如果您尝试更新对象 id=n（其中 n 提供给您）而不首先检查它是否存在，那么您在更新逻辑中缺少验证步骤，这也不好。

【参考方案7】：

过度使用晦涩难懂的 HTTP 错误代码是个坏主意。浏览器有时会以无益的方式做出反应，从而混淆情况。坚持使用 404。

【讨论】：

该死的你给了很好的建议 :( 强迫症不是 404 所有的事情都是真实的。

404 错误对于区分错误的 URI 和未找到的实体有点模棱两可。需要一个新的标准代码来消除 404 的歧义。

我更喜欢返回 204 空内容而不是返回模棱两可的状态码

这篇文章 (kinsta.com/blog/http-status-codes) 描述了“200s：服务器接收、理解和处理浏览器请求时返回的代码”的 HTTP 代码分组。 vs “400s：表示请求有问题的代码”。基于此，在我看来，如果逻辑成功地通过 ID 查询数据库中的某些内容，并且没有找到该 ID 的任何内容，则不存在“请求问题”，而是“成功查询数据”找不到符合条件的数据”，HTTP 204 似乎比 HTTP 404 更合适。

@hsnslh 204 是错误的，因为如果当前显示的内容没有更改，则可以使用它。只有某些标头字段可能会有所不同。我还使用此状态代码作为缺少 404 区分。总的来说，我想说最重要的是记录您在每种情况下使用的状态代码。此外，适当的错误按摩总是有帮助的。

【参考方案8】：

404 就好了。 HTTP/1.1 Status Code Definitions from RFC2616