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

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

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

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

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

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

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

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

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

我知道这已经是姗姗来迟了，但是现在，在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:

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