考慮される API には 2 つの制限があります。
- 一日限定。
- 同時実行制限。
リクエストがキューに入れられていない場合、どの HTTP レスポンス コードを提供する必要がありますか?
これまでの 2 つのオプションは 409 と 503 のようです。とはいえ、503 は API サーバー自体に問題があることを示しているようであり、それを呼び出しているユーザーがクォータを使い果たしたわけではありません。
さらに読むと、見つかりました429 Too Many Requests
(RFC 6585)。
429 要求が多すぎます
429 ステータス コードは、ユーザーが
一定時間内に送信したリクエストが多すぎることを示します (「レート制限」)。
応答表現には、状態を説明する詳細を含める必要があり (SHOULD) 、新しい要求を行う前に待機する時間を示す Retry-After ヘッダーを含めることができます (MAY) 。例えば:
HTTP/1.1 429 Too Many Requests Content-Type: text/html
Retry-After: 3600
<html>
<head>
<title>Too Many Requests</title>
</head>
<body>
<h1>Too Many Requests</h1>
<p>I only allow 50 requests per hour to this Web site per
logged in user. Try again soon.</p>
</body> </html>
この仕様は、オリジンサーバーがユーザーを識別する方法や、リクエストをカウントする方法を定義していないことに注意してください。たとえば、リクエストレートを制限しているオリジンサーバーは 、リソースごと、サーバー全体、または一連のサーバー間でのリクエスト数に
基づいて制限を行うことができます。
同様に、認証資格情報またはステートフル Cookie によってユーザーを識別する場合もあります。429 ステータス コードの応答をキャッシュに格納してはなりません (MUST NOT)。
これはまさに私が探していたもののようです。
他の回答ありがとうございます。
私の意見では、適切なステータスはありません。420 enhance your calm
Twitterがステータスを作り上げました。文書化する限り、問題はありません。
私の意見では403 Forbidden
、理由を指定したとしても、RFC は要求SHOULD
を繰り返さないと言っています。これは、私がそれを変更しない限り、その要求が拒否されることを考えさせます。
いくつかの API ベンダーは、503 を使用して、API 使用条件に従って指定されたレート制限を超えていることを示しています。
Amazon EC2 とさまざまな Google API が同じことを行っています。「503 rate limit」で Google 検索を試すと、それに対応する多くの API が見つかります。詳細なメッセージを提供し、API ドキュメントにそれが明確に記載されている限り、API のユーザーはそれで問題ありません。