建议的“达到请求限制”的HTTP REST状态代码

我正在整理一个REST服务的规范，其中的一部分将包含在整个服务范围内以及一组资源或单个资源上限制用户的功能。同样，这些超时可以按资源/组/服务进行配置。

我只是在浏览HTTP 1.1规范，并试图决定如何与客户端通信，因为请求已达到极限，因此无法满足请求。

最初，我认为客户端代码403 - Forbidden就是这样，但从规范中可以看出：

授权将无济于事，不应重复请求

困扰着我

实际上似乎503 - Service Unavailable是一种更好的用法-因为它允许通过使用Retry-After标头来传递重试时间。

将来我可能会希望通过电子商务支持“购买”更多的请求（在这种情况下，如果客户端代码402 - Payment Required已完成，那就太好了！）-但我认为这也同样可以被压缩为503响应。

您认为我应该使用哪个？还是有我没有考虑过的另一个？

429请求太多

用户在给定的时间内发送了太多请求。旨在与速率限制方案一起使用。RFC 6585 附加HTTP状态代码中已接受此代码。

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

在某种程度上，您可以随意使用这些代码，但我同意您可以使用503，或者如果愿意402，可以使用，而没有人可以抱怨您正在破坏事物。

编辑：纯粹主义者可能会说您应该从503开始，然后在有可能付款时切换。

评论中的一个很好的补充：

4xx表示客户端的错误，可以由他们采取某种措施来修复，而5xx表示服务器上的问题，客户端无法解决。因此，在您的情况下，使用4xx更合适，因为（i）服务器的行为完全正确，并且（ii）客户端可以通过减慢速度或购买更多信用来“修复”错误。确切的分辨率可以在429响应的正文中指出。– Mike Chamberlain 7小时前