当出现错误时，我们是不是应该强调返回哪个特定的 HTTP 响应代码？

Posted 2023-02-19

【中文标题】当出现错误时，我们是不是应该强调返回哪个特定的 HTTP 响应代码？

【英文标题】：Should we stress which specific HTTP response code to return when there's an error?当出现错误时，我们是否应该强调返回哪个特定的 HTTP 响应代码？

【发布时间】：2020-11-17 13:44:36

【问题描述】：

我正在尝试确定在各种错误条件下将哪个 HTTP 状态代码返回给其余客户端。我觉得这个任务压力很大，因为阅读 HTTP 状态码定义就像阅读宪法一样，每个人对同一件事的理解可能不同。

例如，有些人说如果找不到请求的资源，则返回 404 Not Found，而有些人说不应该，因为这意味着端点不可用。

另一个例子是这篇文章： What HTTP response code to use for failed POST request?，答案建议返回 422 Unprocessable Entity 而不是通用错误 400 Bad Request。

我的问题是，为什么不从简单开始，对所有错误返回 400 Bad Request，在响应正文中提供上下文，并且仅在有明显价值时才包含更多 HTTP 状态代码？

例如，之前我们在应用访问令牌过期时返回 200 OK。为了帮助应用解决此问题，我们在响应中提供了一个内部错误 ID，以便客户端可以使用其刷新令牌请求新的访问令牌。但是我们意识到，通过返回 401 Unauthorized，客户端的实现可以简单得多，因为它使用了库。现在我们认为通过添加一个新的 HTTP 状态码，这里有一个明显的价值。

所以再次总结我的问题，是否需要强调返回哪个特定的 HTTP 状态代码？如果响应正文中提供了上下文，在我的第二个示例中返回 400 有什么问题？

【问题讨论】：

虽然 4xx 范围内的响应代码通常被认为是由客户端引起的故障，但我喜欢 Jim Webber 的看法，他将状态代码视为coordination data，在流程的每个步骤中，我们都知道是否有某事进展顺利或糟糕，如果出现问题，它会为我们提供有关如何解决问题的反馈。

【参考方案1】：

我觉得这个任务压力很大，因为阅读HTTP状态码定义就像阅读宪法一样，每个人对同一件事的理解可能不同。

最重要的是要认识到 HTTP 状态代码属于 transporting documents over a network 域，而不是您的业务域。请记住，基本思想是每个 Web 服务器上的每个资源都以相同的方式理解状态代码，而通用组件（如 Web 浏览器）不需要任何特定资源的特殊知识即可正确解释状态代码。

响应的正文是您将资源特定信息传达给客户端的方式。

我的问题是，为什么不从简单开始，对所有错误返回 400 Bad Request，在响应正文中提供上下文，并且仅在有明显价值时才包含更多 HTTP 状态代码？

“明显的价值”就是全部技巧，不是吗？也就是说，是的，您可以对所有客户端错误使用400 Bad Request，就像您可以对所有请求使用 POST 一样。但这样做隐藏了通用组件可以利用的意义。

过去，401 Unauthorized 是您需要特定状态代码的首选示例 - 一直匿名提交请求的浏览器会知道此特定请求需要授权凭据，并通过查看其他响应中的元数据可以确定如何编写新请求（例如，通过向操作员询问用户名和密码，然后将该信息编码到适当的标头中）。

注意这里的目标受众；我们没想到人类会理解 401 的含义；我们希望通用工具能够理解 401 的含义，并采取适当的行动。您在网络域上正确使用传输文档中的元数据通过为我的通用客户端提供智能所需的信息来改善我的体验。

请注意以上对文件传输信息的强调。当您尝试传达有关您的域中问题的信息时，这些详细信息确实属于响应正文。 403 Forbidden（我理解您的要求，但我不愿意这样做）在特定请求违反您的域协议时经常出现。

毕竟，我们不希望通用组件具有特定于我们的域的自定义。