在HTTP头部或响应主体中显示REST错误消息？

Question

我有一个REST服务，向iPhone和Android客户端提供服务。目前，我遵循HTTP代码200、400、401、403、404、409、500等。

我的问题是，在哪里推荐放置错误的原因/描述/原因？是否更合理让REST API在头部始终具有自定义Reason呢？

< HTTP/1.1 400 Bad Request - Missing Required Parameters.
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked

或者将其通过JSON放入响应体中会更好吗？

< HTTP/1.1 400 Bad Request
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: application/json
{ "error" : "Missing Required Parameters" }

- James Cowhen

---

现今，常见的做法是添加自定义头部，例如 'X-HTTP-Error-Description: Missing required parameters'。 - andreszs

Answer 1

引用HTTP规范中关于400.x错误代码的描述:

4xx状态码是为客户端出现错误时提供的。除非是响应HEAD请求，否则服务器应该包含一个实体，其中包含错误情况的解释，以及它是临时还是永久性条件。这些状态码适用于任何请求方法。用户代理应该向用户显示任何包含的实体。

将错误消息作为实体包含在HTTP响应体中是最佳实践 - 无论是JSON、纯文本、格式化HTML还是其他你想要使用的格式。

- Perception

Answer 2

最好将错误详细信息放在正文中。此外，许多（大多数/几乎所有，例如WSGI）服务器和客户端不支持更改错误代码的名称 - 将它们视为固定对（因此例如400始终是“Bad Request”，而不是“Bad Request - 您忘记指定用户ID”）。即使它们不会出现故障，它们也不会关心您为特定错误代码提供的特殊名称。

- Tadeck

Answer 3

错误不应该出现在正文中，应该出现在警告头部。

警告通用HTTP头包含与消息状态可能存在的问题有关的信息。

参考资料

- B Seven

---

最好使用“官方”的标题。然而，“Warning”正如其名称所示，并非用于错误。RFC（7234）表示： 与真正的失败不同，使用警告而不是错误状态码区分这些响应。 - Frans

注意：警告头很快就会被弃用；有关更多详细信息，请参见警告（https://github.com/httpwg/http-core/issues/139）和警告：头文件和stale-while-revalidate（https://github.com/whatwg/fetch/issues/913）。 - Bizmarck