推荐的HTTP状态代码，用于“超出计划限制”响应

我正在为一个项目设计REST API，在该项目中，用户始终处于多个“计划”之一中-每个计划都定义了一些资源限制，例如帐户可能拥有的最大用户数或他们可以上传的最大数据数。一旦达到这些限制之一，用户就可以升级他们的计划（基本上是付费）以获得更多资源。

我想返回一个特殊的状态代码，该状态代码表示由于帐户资源限制而无法执行操作的情况，因此升级计划将解决此问题-例如，如果用户使用了其存储容量的100％，并尝试上传其他文件，他们将收到此回复。

候选人是恕我直言：

• 403 Forbidden -但是，我想区分这种情况和其他情况，即用户只是缺乏执行此操作的权限。

• 401 Unauthorized -不是一个好主意，我们正在使用它来解决与身份验证相关的问题。

• 402 Payment Required -有道理，但我担心使用非标准但保留的状态码

• 甚至不太标准的423 Locked东西，例如将来我们不太可能将其用于其他任何东西

另一种选择是使用一些非常标准的东西，例如，403但在响应主体中指出错误的细节。

我想知道您相信哪种方法（a）从长远来看效果最好，并且（b）将更好地坚持RESTful原则。

我认为403是唯一合理的回应，尽管405 Method Not Allowed或409 Conflict可能是可以接受的，但我认为这两者都不如403那样好：

服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。如果请求方法不是HEAD并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝的原因

如果返回403错误，则会包含一些有关为什么拒绝资源的信息-无效权限只是最常见的情况，超出限制的差异不大-您没有权限，因为超出了限制。

我认为403是错误的，因为403适用于您无法访问资源且无法获得访问权限的情况。对于您的客户而言，显然有一种获取访问权限的方法：付款。

401确实是错误的，因为您不仅将其用于身份验证，而且这就是它的用途。

由于您正在编写API，因此我假设其他人将不得不编写使用该API的代码，并且该人需要阅读您的API规范。您可能会使用429“请求过多”。它通常用于限制速率（例如，客户每天可以发出100个请求），但确实适用于您的情况。我认为402（需要付款）也可以接受。取决于您希望人们使用哪些工具来使用您的API。429的风险是，聪明的工具尝试每分钟/小时/天发送更少的请求，并且永远不会成功。

顺便说一句，根据https://tools.ietf.org/html/rfc6585，429错误还应该包含描述问题性质的html消息，因此，如果您提供的话，很有可能实际上告诉用户了问题所在您回复中的信息。

WebDAV 为此使用了HTTP 507存储不足，并在请求正文中包含了一个超出配额的附加错误代码，以区别于其他类型的存储限制。