RESTAPI的响应应该包含HTTP结果代码吗？

我正在查看RESTAPI的规范，设计人员对错误条件有以下json响应体

{
    "status": "",
    "serviceSpecErrorCode": "",
    "userMessage": "",
    "devMessage": "",
    "moreInfo": ""
}

其中，

“status”

是HTTP响应代码的副本（例如404）

这样做是不好的做法吗？这样做有什么理由/好处

编辑1: 我应该提到，这是一个尚未实现的规范。我要求的原因更多的是最佳设计/实践，因为我们现在可以在实施之前更改它

编辑2: 对不起，根据一些答案，我还应该提一件事。。。

“status”

值将与HTTP响应代码相同。他们永远不会不同

这样做有什么理由/好处

URL模式、请求方法、状态代码和响应模型因API而异，只是为了混淆REST服务的消费者。但是，他们说，SOAP是不好的，因为它是XML和RPC，没有一个头脑正常的人会使用它们，阿米丽特

随他们的便

[他们为什么]这样做

它允许更细粒度的状态代码，因此您可以返回一个更具体的状态代码，而该代码不适合于一个服务响应（因为当然存在一个特定的场景并不完全适合任何现有的场景），这导致您必须深入到它们的文档中，查找服务响应可以包含哪些特定的状态代码，并据此处理

他们也可以决定这样做，因为他们希望他们的服务消费者不知道如何从HTTP响应中读取特定编程语言和/或框架中的状态代码。

“带手表的人知道现在几点。带两块手表的人永远不知道。”

因此，虽然我可以获得HTTP状态，但我会忽略响应主体中的状态代码（但我会记录它以防万一），其余字段可以为您提供更好的提示，说明当响应不是预期的响应时会发生什么。

这是多余的

HTTP API应使用最适合其用途的HTTP状态代码。此代码应可供任何客户端使用。如果代码不同，“状态”代码可能是其他代码，但正如您所指出的，它只是一个副本

---

没有任何好处，这会导致混乱。客户机开发人员将开始依赖“状态”代码，而您永远无法摆脱它。

对我来说，这是一个非常糟糕的主意。他们当然可以对400级以上的代码执行此操作，但如何对500级代码执行此操作？很多时候，当您的应用程序甚至不知道发生了什么时，它们会被发送

当然，设计自己的代码（如1、2、3等）或其他对应用程序客户更有用的代码是有意义的。

简短回答 这是多余的。它复制了HTTP状态代码本身中可用的信息，从而带来了两者之间不一致的可能性

如果包含在响应负载中，则状态代码应仅为建议代码，并且必须与实际HTTP响应中的状态代码相同

长话短说 当返回HTTP API的问题详细信息时，您可能需要查看：

本文档将“问题详细信息”定义为在HTTP响应中携带机器可读的错误详细信息的一种方式，以避免为HTTP API定义新的错误响应格式

根据该文档，除了其他元素外，问题详细信息对象还可以包含HTTP状态代码：

• 状态

  （编号）：源服务器为此问题生成的HTTP状态代码

RFC还规定了以下内容：

状态

成员（如果存在）仅为顾问；它传递为方便消费者而使用的HTTP状态代码。生成器必须在实际HTTP响应中使用相同的状态代码，以确保不理解此格式的通用HTTP软件仍能正常运行

status

成员复制HTTP状态代码本身中的可用信息，从而导致两者之间可能存在分歧。它们的相对优先级不清楚，因为不一致可能表明（例如）中间人在传输过程中修改了HTTP状态代码（例如，通过代理或缓存）

---

感谢您的详细回复和RFC参考！