因此，一开始我想用200 OK和一个特定的XML有效负载(即。付我们更多的钱，你就能得到你需要的存储空间!)但我停下来想了想，这似乎有点像肥皂(/惊恐地耸耸肩)。

我不会返回200，除非这个请求真的没有问题。在RFC2616中，200表示“请求已成功”。

如果客户端的存储配额已经超出(无论出于什么原因)，我将返回403 (Forbidden):

服务器理解请求，但拒绝执行。授权没有帮助，请求不应该重复。如果请求方法不是HEAD，并且服务器希望公开请求没有被完成的原因，它应该在实体中描述拒绝的原因。如果服务器不希望将此信息提供给客户机，则可以使用状态代码404 (not Found)。

这将告诉客户端请求是OK的，但是它失败了(200不会这样做)。这也使您有机会在响应体中解释问题(及其解决方案)。

你想到的其他具体错误情况是什么?

主要的选择是是否将HTTP状态代码作为REST API的一部分。

这两种方法都很有效。我同意，严格地说，REST的思想之一是您应该将HTTP状态代码用作API的一部分(成功操作返回200或201，根据不同的错误情况返回4xx或5xx)。但是，没有REST警察。你可以做你想做的。我曾见过更过分的非rest api被称为“RESTful”。

在这一点上(2015年8月)，我建议你使用HTTP状态代码作为你的API的一部分。在使用框架时，现在比过去更容易看到返回代码。特别是，现在比过去更容易看到非200返回的情况和非200响应的主体。

HTTP状态代码是api的一部分

You will need to carefully pick 4xx codes that fit your error conditions. You can include a rest, xml, or plaintext message as the payload that includes a sub-code and a descriptive comment. The clients will need to use a software framework that enables them to get at the HTTP-level status code. Usually do-able, not always straight-forward. The clients will have to distinguish between HTTP status codes that indicate a communications error and your own status codes that indicate an application-level issue.

HTTP状态代码不是api的一部分

The HTTP status code will always be 200 if your app received the request and then responded (both success and error cases) ALL of your responses should include "envelope" or "header" information. Typically something like: envelope_ver: 1.0 status: # use any codes you like. Reserve a code for success. msg: "ok" # A human string that reflects the code. Useful for debugging. data: ... # The data of the response, if any. This method can be easier for clients since the status for the response is always in the same place (no sub-codes needed), no limits on the codes, no need to fetch the HTTP-level status-code.

这里有一个类似的想法:http://yuiblog.com/blog/2008/10/15/datatable-260-part-one/

主要问题:

请确保包含版本号，以便稍后在需要时更改api的语义。 文档…

记住，有比HTTP/1.1 rfc中定义的状态码更多的状态码，IANA注册表在http://www.iana.org/assignments/http-status-codes。就你提到的情况来说状态码507听起来不错。

有两种错误。应用程序错误和HTTP错误。HTTP错误只是为了让AJAX处理程序知道一切正常，不应该用于其他任何事情。

5xx服务器错误

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295 )
507 Insufficient Storage (WebDAV) (RFC 4918 )
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
510 Not Extended (RFC 2774 )

2 xx成功

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)

然而，如何设计应用程序错误实际上取决于您自己。例如，Stack Overflow发送一个具有响应、数据和消息属性的对象。我认为响应包含true或false，以指示操作是否成功(通常用于写操作)。数据包含有效负载(通常用于读取操作)，消息包含任何额外的元数据或有用消息(例如响应为false时的错误消息)。

不要忘记5xx错误以及应用程序错误。

在这种情况下，409(冲突)怎么样?这假设用户可以通过删除存储资源来解决问题。

否则507(不完全标准)也可以工作。我不会用200，除非你一般用200来表示错误。

正如其他人指出的那样，在错误代码中包含响应实体是完全允许的。

请记住，5xx错误是服务器端错误，也就是说客户端不能更改其请求的任何内容以使请求通过。如果超出了客户端的配额，那肯定不是服务器错误，所以应该避免5xx。

如果超出客户端配额，则是服务器错误，在本例中请避免5xx。

根据现有的“最佳实践”来建模你的api可能是正确的方法。 例如，Twitter是如何处理错误代码的 https://developer.twitter.com/en/docs/basics/response-codes

同意了。REST的基本理念是使用web基础设施。HTTP状态代码是消息传递框架，允许各方在不增加HTTP有效负载的情况下相互通信。它们已经是传递响应状态的通用代码，因此，要真正实现RESTful，应用程序必须使用这个框架来通信响应状态。

在HTTP 200信封中发送错误响应具有误导性，并迫使客户端(api使用者)解析消息，很可能以非标准或专有的方式。这也是低效的——您将迫使您的客户端每次都解析HTTP有效负载以了解“真实的”响应状态。这增加了处理，增加了延迟，并为客户端创建了一个出错的环境。

我知道这已经是姗姗来迟了，但是现在，在2013年，我们有了一些媒体类型来以通用的分布式(RESTful)方式处理错误。看到盾”。错误”,应用程序/盾。error+json (https://github.com/blongden/vnd.error)和“HTTP api的问题细节”，application/ Problem +json (https://datatracker.ietf.org/doc/html/draft-nottingham-http-problem-05)。

为你的API选择正确的HTTP错误代码的一个很好的资源: http://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html

文章节选如下:

从哪里开始:

2XX / 3XX:

4XX:

5XX:

请遵守协议的语义。使用2xx表示成功响应，使用4xx和5xx表示错误响应——无论是您的业务异常还是其他。如果协议中的预期用例是使用2xx进行任何响应，那么它们首先就不会有其他状态码。