我一直在查看 REST API 的示例，例如 Netflix http://developer.netflix.com/docs/REST_API_Reference#0_59705 和 Twitter，它们似乎将错误消息放在 statusText 标头响应而不是 responseText 中。我们正在开发一个内部 RESTful api，我主张发送自定义 statusText 消息并忽略 responseText。
在我们的应用范围内，当用户尝试做他们不应该做的事情时，我们会返回错误 400，并且将在用户界面中更新的唯一错误消息将与 400 一起传递. 我认为消息应该作为修改后的 statusText 发送，但是其中一位工程师（对 REST 的了解比我少）正在争论在 responseText 中发送它。
最好的方法是什么？
【问题讨论】：
标签： rest
HTTP 定义您应该在响应实体正文中放置描述性错误消息，即 responseText。
statusText 不被任何客户端渲染或处理。
我将使用状态文本作为错误消息类型，即 400 客户端错误，并使用正文来描述可以呈现给用户的问题，无论客户端可以处理何种格式。
编辑：请注意，从那时起，存在一种新的标准化格式，以标准方式将错误详细信息传达回客户端，您可以在 https://www.rfc-editor.org/rfc/rfc7807 找到它，我会推荐它。
【讨论】：
我认为你是对的，一般的方法是使用 HTTP 内置的现有错误机制。
一般来说，尝试将您的错误映射到现有的 HTTP 错误，例如，如果他们请求他们无权访问的内容，则返回 403 错误。
如果他们请求的内容不存在，则返回 404。
【讨论】：
根据 HTTP 规范 (rfc2616)：“HTTP 状态码是可扩展的”
但是我不认为为每个不同的错误消息创建新状态是正确的方法：
如果您找不到任何符合您要求的类别，我会说适当地选择 HTTP 状态 (HTTP Status Code Definitions) 创建一个自定义类别（但我相信您会这样做）并将错误消息放入 HTTP 响应正文中。
【讨论】：
为您的响应选择适当的状态代码非常重要，因为它是自我描述性消息的关键促成因素。
实体主体应该是资源状态的表示，理想情况下包含指向应用程序中可用的下一个状态的超链接
【讨论】：
Http 状态码是非常自我解释的，应该这样使用。使用验证错误返回 200 OK 是相当肥皂和误导性的。任何 REST 客户端实现 4xx 和 5xx 错误都会进入错误块，如果您真的想将响应正文用于非 2xx 响应，这实际上取决于具体情况。
【讨论】：