即使请求失败，HTTP 响应始终返回响应代码 200，并且返回状态代码是 REST 的一部分

Question

我最近加入了一个新项目。在这个项目中，服务中的所有 API 总是返回状态代码 200。即使响应应该是 400 或 404，API 也会返回状态代码 200。

我问了 API 不返回其他响应代码的原因，程序员告诉我他们不使用响应代码。他们将信息放入体内。

例如，缺少一些必填字段，它们返回响应状态代码 200，但正文返回这样

{"result" : "fail"}

如果未经授权的用户尝试访问，状态码为 200，则正文返回如下

{"result" : "unautherized"}

我之前所做的非常不同，我总是按案例指定状态代码并尝试返回合适的状态代码和消息。我认为这是 HTTP 协议的一部分。但是，他们告诉我，像 400、404、300 这样的指定状态代码是 RESTful API 的一部分，并且始终返回 200 是正确的状态代码，因为服务器响应并且它处于活动状态。APIs，除了500，总是要返回200。因为当服务器挂掉时，它不能返回任何东西。

所以这些是问题。

1. 服务器应该总是返回状态代码 200 除非服务器死机？
2. 指定各种状态代码是 REST API 的一部分吗？
3. 不使用状态码很常见吗？

Answer 1

服务器应该总是返回状态代码 200 除非服务器死机？

几年前我在软件工程上问过同样的问题：Web 应用程序是使用 HTTP 作为传输层，还是算作 HTTP 服务器的一个组成部分？. 另请参阅我是否应该使用 HTTP 状态代码来描述应用程序级事件。

指定各种状态代码是 REST API 的一部分吗？

不，REST 与传输无关。它可以在 HTTP 之上使用，但不需要。因此它没有说明任何关于状态代码的内容。

不使用状态码很常见吗？

取决于你问谁。

这是一个偏好问题。我非常不喜欢“场景 X 最合适的状态代码是什么？” 问题。此外，还有：

• HTTP 状态代码
• HTTP 响应状态代码 – REST API 教程

还有很多其他的。我记得有一个网站提供了一个流程图来确定（最）合适的状态代码。

一般来说，不要打扰。一致性和完整的文档比分配适当的数字更重要。

Answer 2

我加入了一个使用完全相同策略的项目——在响应正文中嵌入状态消息，并将状态代码保留为“始终” 200。出于一致性原因，在软件维护期间最好遵循现有策略。但是，不建议任何新项目使用它，原因如下：

1. “指定状态代码如 400、404、300”遵循 RESTful 设计，但它不是 REST 的一部分。实际上，302（重定向）、401（基本和摘要式身份验证）、404（Web 服务器中默认未找到页面）、500（默认服务器错误页面）的使用在几十年前就很流行，早在 RESTful API 出现之前就已经流行了（我知道 RESTful 是在几十年前提出的）以前是这样，但最近几年才流行）。

2. “始终返回 200 是正确的状态代码，因为服务器响应并且它处于活动状态”。这是不正确的。如果是，则只能200用于状态代码——只要服务器“活动”，它就可以返回消息。500也不可接受，因为在这种情况下，服务器仍然“活着”，它不会死亡......那么，由于状态代码应该始终是200，为什么我们需要代码？

3. “不使用状态码很常见吗？” 。事实上，情况恰恰相反。随着RESTful API设计方案越来越流行，越来越多的项目开始使用HTTP状态码来传递消息语义。但无论如何，这是一个基于意见的观点。