API バージョン1.1のレート制限では、主にユーザーごとの制限を基本に考えています — さらに正確に説明すると、あなたが制御するアクセストークンごとの制限になります。 あるメソッドでレート制限枠ごとに15回のリクエストが実行できる場合、有効なアクセルトークン一つあたり15回のリクエストを実行することができます。 これはOAuthを使う時にユーザーごと/アクセストークンごとの制限があったAPI バージョン1と同じです。
アプリケーション限定認証を使用する場合、レート制限はアプリケーション全体に対して適用されます。 あるメソッドでレート制限枠ごとに15回のリクエストが実行できる場合、アプリケーション全体で15回のリクエストを実行することができます。 この制限は、ユーザーごとの制限とは完全に別個のものと見なされます。
API バージョン1.1のレート制限は15分間隔に分割されています。バージョン1.0では60分ごとだったので、そこから変更されています。 さらに、全ての1.1エンドポイントでは認証が必須となっており、もはや非認証呼び出しとレート制限の兼ね合いを考える必要はありません。
While in version one of the API, an OAuth-enabled application could initiate 350 GET-based requests per hour per access token, API v1.1’s rate limiting model allows for a wider ranger of requests through per-method request limits. There are two initial buckets available for GET requests: 15 calls every 15 minutes, and 180 calls every 15 minutes.
当面の間、検索は15分枠あたり180クエリに制限されていますが、いずれ変更するかもしれません。バージョン1.1では検索クエリの保存にも認証が必要です。
バージョン1.1では新しいHTTPヘッダが返されます。ヘッダにはあなたのアプリケーションに適用される使用メソッドのレート制限が記載されているので、中身を確認するようにしてください。 これらのヘッダはAPI バージョン1.0のレート制限のものと似ていますが、全く同じものではないので注意してください。
HTTP ヘッダはコンテキスト形式なので注意してください。 アプリケーションだけの認証を使用した場合、HTTPヘッダはアプリケーションコンテキストのレート制限を表します。 ユーザーベース認証を使用した場合、HTTPヘッダはユーザーアプリケーションコンテキストのレート制限を表します。
X-Rate-Limit-Limit:指定したリクエストにおけるレート制限の上限
X-Rate-Limit-Remaining:15分枠のうち、残っているリクエスト回数
X-Rate-Limit-Reset:レート制限がリセットされるまでの残り時間。UTC エポック秒形式
アプリケーションが指定したAPIエンドポイントのレート制限を超過した場合、現状Twitter APIではAPI固有のコードではなくHTTP 429 “Too Many Requests”のレスポンスコードを返します。
指定したエンドポイントのレート制限に引っかかった場合は、以下のような HTTP 429 メッセージのbodyを見ることになるでしょう:
{ "errors": [ { "code": 88, "message": "Rate limit exceeded" } ] }
レート制限の残り使用回数を把握するには、定期的に GET application / rate_limit_statusを使用することを検討してください。 HTTP ヘッダに記載されたレート制限情報と同様に、このエンドポイントの応答では指定したコンテキストのレート制限状態を返します — アプリケーション限定認証を使用している場合、制限内容は使用するリソース群によって変わります。ユーザーベース認証を使用している場合、制限内容は使用するユーザーによって変わります。
システムから “データを読み取る(reads)”場合のレート制限は基本的にユーザーごと、アプリケーションごとに定義され、システムへデータを書き込む(writes)場合のレート制限は ユーザーレベルでのみ定義されます。言い換えれば、読み込みのレート制限では以下のような場合が考えられます。:
これを、ユーザーごとに定義される書き込みのレート制限と比べてください。 So if user A ends up posting 5 Tweets with application Z, then for that same period, regardless of any other application that user A opens, those 5 POSTs will count against any other application acting on behalf of user A during that same window of time.
最後に、返されたレート制限の値に矛盾がある場合や、ヘッダ部分が一切ない場合があります。おそらくメモリキャッシュがリセットされたか、システムが別のインスタンスを処理していたためメモリキャッシュがビジー状態だったのかもしれません:この値を再取得すると、今とは違う値が取得されるかもしれません。 我々は整合性を保つために最大限努力しますが、エラーによって矛盾が発生した場合はアプリケーションで余計なメソッド呼び出しが必要になってしまいます。
後述するヒントによって、コードを安全に記述してレート制限が発生する可能性を減らす助けになるでしょう。 あなたがアプリケーションに実装しようとしている機能については、レート制限の観点から実装不可のものもいくつかあるでしょう。 特に検索結果を最新状態に保つような機能などは。 アプリケーションでリアルタイムの情報を重視するのであれば、The Streaming APIs と合わせて User streams と Site streamsを参照してください。
頻繁に使用すると思われる場合は、APIの応答結果をアプリケーションやサイトの内部に保存します。例えばウェブサイト上の全てのページで、表示されるたびに毎回Twitter APIを実行するのはやめてください。 そうはせずに、たまにAPIを実行して応答結果をローカルキャッシュに保存してください。ユーザーがウェブサイトを表示した時に保存された応答結果を読み込んでください。
あなたのサイトで多くのTwitter ユーザーの動向を記録している場合は (例えば、ユーザーのTwitter利用に関する現在の状態とこれまでの統計を取得しているなど)、 あなたのサイトに最近ログインしたユーザーのデータのみリクエストすることを検討してください。
If your application monitors a high volume of search terms, query less often for searches that have no results than for those that do. By using a back-off you can keep up to date on queries that are popular but not waste cycles requesting queries that very rarely change. あるいは、ストリーミングAPIの使用 と検索キーワードのフィルタを検討してください。
アプリケーションのみの認証を使用したリクエストは、ユーザーごとのレート制限とは区別して評価されます。 多くの場合、この追加のレート制限領域をユーザーベースレート制限の“予備”として使いたいはずです。
我々はあなた方に、レート制限を尊重することをお願いしています。もしあなたやあなたのアプリケーションがレート制限を無視した行為をした場合、我々はブラックリストへの登録を行います。 ブラックリストに登録されると、Twitter APIからの応答を取得できなくなります。あなたやあなたのアプリケーションがブラックリストに登録され、それが何かの間違いだと思った場合は、 サポートページのメールアドレスに連絡することができます。迅速対応ができるようにするため、以下の情報を添えてください:
ストリーミング API には、長時間の接続に適したレート制限とアクセスレベルがあります。詳細については ストリーミングAPIドキュメントを参照してください。
ストリーミングAPIを活用すれば、レート制限に左右されずより独創的にTwitter APIを使用することができます。
ストリーミングAPIのレート制限についてはストリーミングエンドポイントに接続するに詳細が記載されています。
我々のAPIのレート制限枠時間は、現在15分の長さになっています。API レート制限: 早見表 のページを開き、リソースごとの制限を参照してください。
上記の早見表に記載されていない endpoints/resources は、既定でユーザーあたり15リクエストなので注意してください。