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

Question

我正在尝试确定在各种错误条件下将哪个 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 有什么问题？

标签： node.jsresthttpapi-designhttp-response-codes

Answer 1

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

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

响应的主体是您如何向客户端传达资源特定信息的方式。

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

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

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

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

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

毕竟，我们并不期望通用组件具有特定于我们领域的定制。