HTTP响应总是返回响应代码200，即使请求失败，返回状态代码也是REST的一部分

Question

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

我问API为什么不返回其他响应代码，程序员告诉我他们不使用响应代码。他们把信息放在身体里。

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

{"result" : "fail"}

如果未经授权的用户试图访问，状态代码为200，身体像这样返回

{"result" : "unautherized"}

我以前做的是非常不同的，我总是通过案例指定状态代码，并尝试返回合适的状态代码和消息。我认为这是HTTP协议的一部分。然而，他们告诉我指定状态代码，比如400, 404, 300，是RESTful API的一部分，总是返回200是正确的状态代码，因为服务器响应了，它是活的。API，总是必须返回200，除了500。因为当服务器死亡时，它不能返回任何东西。

这就是问题所在。

1. 服务器应始终返回状态代码200，但服务器已死亡
2. 指定各种状态代码是RESTAPI的一部分吗
3. 不使用状态代码是常见的吗

Answer 1

团队正在做的事情可能完全适合他们所处的环境。但是将这些模式标记为REST听起来不准确。

我这样说是因为团队似乎没有考虑他们当前的消息传递方案如何与消息交换中的一般参与者协作。

例如，在REST体系结构样式中，缓存是一个重要的关注点。在HTTP中，RFC 7234描述了缓存语义。特别是，有一节介绍了状态代码如何触发缓存失效。这反过来说明，如果您不区分成功和不成功情况下的状态代码，那么通用组件将使不应无效的缓存条目无效。

Answer 2

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

>

指定状态代码如400, 404, 300遵循RESTful设计，但它不是REST的一部分。实际上，使用302（重定向），401（基本和摘要验证），404（Web服务器中的默认未找到页面），500（默认服务器错误页面）是几十年前流行的，远远早于RESTful这些天的API（我知道RESTful是几十年前提出的，但它只是近年来才流行）。

“始终返回200是正确的状态代码，因为服务器已响应并且处于活动状态”。这是不正确的。若是，那个么只有200可以用于状态代码——只要服务器处于“活动”状态，它就可以返回消息<代码>500也不可接受，因为在这种情况下，服务器仍然“活动”，它不会死亡。。。那么，既然状态代码应该总是200，为什么我们需要代码呢？

“不使用状态代码是否常见？”。其实是相反的。随着RESTful API设计方案越来越流行，越来越多的项目使用HTTP状态代码来传递消息语义。但无论如何，这是一个基于观点的观点。

Answer 3

服务器应始终返回状态代码200，但服务器已死亡？

几年前，我在软件工程方面也提出了同样的问题：web应用程序是将HTTP用作传输层，还是将其视为HTTP服务器的一个组成部分？。另请参见我是否应该使用HTTP状态代码来描述应用程序级事件。

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

不，REST与传输无关。它可以在HTTP之上使用，但不需要。因此，它没有提到任何状态代码。

不使用状态代码是常见的吗？

取决于你问谁。

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

• HTTP状态代码
• HTTP响应状态代码–RESTAPI教程

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

一般来说，不用麻烦了。一致性和完整的文档比分配适当的编号更重要。