我最近加入了一个新项目。在此项目中，服务中的所有API始终返回状态码200。即使该响应应为400或404，API也会返回状态码200。
我问了API不返回其他响应代码的原因，程序员告诉我他们不使用响应代码。他们将信息放入体内。
例如，缺少一些必填字段，它们返回响应状态代码200，但是正文返回如下
{"result" : "fail"}
如果未经授权的用户尝试访问，则状态码为200，正文会像这样返回
{"result" : "unautherized"}
我之前所做的工作与以前大不相同，我总是根据情况指定状态代码，并尝试返回合适的状态代码和消息。我认为这是HTTP协议的一部分。但是，他们告诉我指定状态代码（例如400、404、300）是RESTful API的一部分，并且始终返回200是正确的状态代码，因为服务器已响应并且它仍然有效。 API，除500之外，总是必须返回200。因为服务器死亡时，它无法返回任何内容。
这就是问题所在。
答案 0 :(得分：3)
团队的工作可能完全适合他们所处的环境。但是将这些模式标记为REST听起来并不准确。
之所以这样说，是因为听起来好像团队没有考虑他们当前的消息传递方案如何与消息交换中的通用参与者一起工作。
例如，缓存是REST体系结构样式中的一个重要问题。在HTTP中，RFC 7234描述了缓存语义。特别是，有一节专门介绍状态代码如何触发cache invalidation。这反过来又说明，如果您不区分成功和失败情况下的状态码，则通用组件将使缓存的条目无效，而不应使它们无效。
答案 1 :(得分：0)
除服务器死亡外，服务器应始终返回状态码200？
几年前，我在“软件工程”上也问过同样的问题：Do web applications use HTTP as a transport layer, or do they count as an integral part of the HTTP server?。另请参见Should I use HTTP status codes to describe application level events。
指定各种状态代码是REST API的一部分吗？
否，REST与传输无关。它可以 用于HTTP之上，但不需要。因此，它没有说明任何有关状态码的信息。
不使用状态码很常见吗？
取决于您询问的人。
这是优先事项。我非常不喜欢“方案X最合适的状态代码是什么？” 问题。另外，还有：
还有很多其他的。我记得有一个站点提供用于确定（最）适当状态代码的流程图。
通常，不要打扰。一致性和详尽的文档记录比分配适当的编号更为重要。
答案 2 :(得分：0)
我加入了一个使用完全相同的策略的项目-将状态消息嵌入响应正文中，并使状态代码始终为200。出于一致性原因，最好在软件维护期间遵循现有策略。但是，不建议将其用于任何新项目，原因如下：
“指定状态代码，例如400、404、300” 遵循RESTful设计，但它不是REST的一部分。实际上，302（重定向），401（基本和摘要式身份验证），404（Web服务器中默认的未找到页面），500（默认服务器错误）的使用页）在几十年前就流行了，远不及现在的RESTful API（我知道RESTful是几十年前提出的，但仅在最近几年才流行）。
“始终返回200是正确的状态代码，因为服务器已响应并且它还处于活动状态”。。这是不正确的。如果是，则只能将200用作状态代码-只要服务器“处于活动状态”，它就可以返回消息。 500也不可接受，因为在这种情况下，服务器仍处于“活动状态”，它不会死掉……然后，由于状态代码应始终为200，因此为什么需要代码？
“不使用状态代码很常见吗？” 。实际上，这是相反的。随着RESTful API设计方案越来越流行，越来越多的项目正在使用HTTP状态代码来传递消息语义。但是无论如何，这是一个基于观点的观点。