使用我的HTTP状态代码传达原因

Question

构建RESTful服务时，标准做法是返回有效负载（Json）以及HTTP状态代码（比如500,403）吗？我发现有时单独的状态代码不足以调用应用程序。

Answer 1

虽然这项工作正在进行中，但值得一读：Problem Details for HTTP APIs

引自规范：

  

例如，考虑一个表示客户端的响应   帐户没有足够的信用。 403 Forbidden状态码
  可能被认为最适合使用，因为它将通知HTTP-
  通用软件（如客户端库，缓存和代理）   响应的一般语义。

     

但是，这并没有为API客户端提供足够的信息   为什么要求被禁止，适用的帐户余额或如何   纠正问题。如果这些细节包括在中   响应体以机器可读的格式，客户端可以对待它   适当的;例如，触发更多信贷转入   帐户。

     

本规范通过识别特定类型的
来实现这一点   问题（例如，“信用不足”）与URI [RFC3986]; HTTP API可以是   通过在其控制下提名新URI或重用
来实现此目的   现有的。

Answer 2

我也发了一个关于此的问题here

所以最后我会了解编辑2中的内容：返回适当的HTTP状态，并在响应正文中，描述遇到的错误的JSON，如：

HTTP 404
{
  "code": 123,
  "message": "The resource you are looking for does not exists"
}

这是Twitter和其他人的工作方式。

Answer 3

有效负载通常与响应代码一起返回，但通常以通用方式解释响应代码本身。例如，将404返回到接受text / html的客户端的Web服务器可能会在需要这样的响应时提供1个HTML页面。可能会返回其他上下文信息（例如服务器版本，用于调试目的的日志标识符等），但没有任何内容可以指示更具体的原因。

400错误系列意味着它可由客户端操作。添加子错误代码会将客户端紧密耦合到服务器。

Answer 4

子弹形式答案是：

1. 使用HTTP状态码正确
2. 使用描述性错误消息
3. 考虑与其他语言相关的本地化
4. 允许多条消息
5. 如果应用程序要求，则包含其他错误代码
6. 使用字母代码
7. 包含在线资源的链接
8. 支持多种媒体类型
9. 包含时间戳或日志参考
10. 包含HTTP状态代码
11. 不包括堆栈跟踪

您可以在此处找到一个深入的答案：http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html