「リクエスト制限に達しました」の推奨HTTP RESTステータスコード

RESTサービスの仕様をまとめています。RESTサービスの一部には、サービス全体およびリソースのグループまたは個々のリソースでユーザーを調整する機能が組み込まれています。同様に、これらのタイムアウトは、リソース/グループ/サービスごとに構成できます。

HTTP 1.1仕様を調べて、クライアントが制限に達したために要求が満たされないことをクライアントに伝える方法を決定しようとしています。

最初は、クライアントコード403 - Forbiddenが1つであると考えましたが、これは仕様からです。

承認は役に立たず、リクエストは繰り返されるべきではありません

私を悩ませた。

実際に503 - Service Unavailableは、使用するほうが良いようです- Retry-Afterヘッダーを使用することで再試行時間の通信が可能になるためです。

将来的には、eコマースを介してより多くのリクエストを「購入」することをサポートする可能性があります（この場合、クライアントコード402 - Payment Requiredが確定されていればいいと思います！）。

私はどちらを使うべきだと思いますか？または、私が考慮していない別のものがありますか？

429リクエストが多すぎます

ユーザーが一定時間内に送信したリクエストが多すぎます。レート制限スキームでの使用を目的としています。このコードはRFC 6585 Additional HTTP Status Codesで受け入れられています。

   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）サーバーは正確に動作しているからです。429応答の本文に正確な解像度を示すことができます。–マイクチェンバレン7時間前