TwitterのAPI利用制限 ver.1.1
- 2015/03/27
- 11:16
下記のページの日本語訳。一部意訳も入っており、わかりにくい部分にはリンクや説明をつけました。
Twitter API 「API Rate Limits」
https://dev.twitter.com/rest/public/rate-limiting
API ver. 1.1の「Rate Limit」はまずはユーザー毎、もっと正確に言うとユーザーの「access token」毎に認識される。
もしあるメソッドが１つの「Rate Limit」ウィンドウ毎に15リクエストを許可したら、効力のある「access token」毎に15のリクエストを許可するということになる。
これはAPI ver.1における、OAuthの効力がある間の「per-user/per-access token」の制限の方法と似ている。
もし「application-only authentication」を利用すると、「rate limit」はアプリケーション全体で維持される。
もしあるメソッドが「rate limit」ウィンドウ毎に15のリクエストを許可した場合、それはあなたのアプリケーションの代わりにウィンドウ毎に15のリクエストを許可することになる。これはユーザーごとの制限とは完全に別のものと認識されている。
API ver.1.1 の「rate limit」は15分のインターバルで区切られており、60分毎のブロックで扱っていたver.1.0からの変更である。加えて、すべての1.1のエンドポイントは認証が必要になるため、非認証によるコールと「rate limit」はもう存在しない。
API ver.1においてOAuthを利用できるアプリケーションは1時間毎、「access token」毎にGETベースのリクエストを３５０発生させることができたが、ver.1.1の「rate limit」モデルではメソッド毎のリクエスト制限によって幅広いリクエストを許可する。GETリクエストには次の２つの初期バケットが可能。
GETリクエスト：
15コール / 15分
180コール / 15分
参照→ https://dev.twitter.com/rest/public/rate-limits
検索は15分に180の「rate limit」があるが、もしかしたら緩める可能性もある。検索に関してもver1.1では認証が必要であることに注意。
省略
「read」の「rate limit」はユーザー毎、アプリケーションごとに定義されている一方、
「write」の「rate limit」はユーザーレベルで単独に定義されている。
別の言い方をすると「read」の「rate limit」は下記のようなシナリオで認識される：
・ユーザーAがアプリケーションZを起動、ZがユーザーAのメンションタイムラインを１５分ウィンドウで１０回コールする。するとアプリケーションZはそのウィンドウでは５コールだけ残すことになる
・その後ユーザーAがアプリケーションXを起動、XがユーザーAのメンションタイムラインを３回コールする。この時アプリケーションXはこのウィンドウにおいて１２コール残すことになる。
・つまり、アプリケーションXの残りのコール数は同じユーザーAによる利用にもかかわらず、アプリケーションZのそれからは独立している。
これに比べて「write」はユーザー毎に定義されている。すなわち、もしユーザーAがアプリケーションZで５回のツイートをした場合、同じ期間においてAが開いた他のアプリケーション上においても５回のPOSTはカウントされることになる。
最後に、我々が返す「rate limit」には間違いがあるかも知れないし、ヘッダーを全く返さないこともあるかも知れない。恐らくキャッシュのリセットやキャッシュがビジー状態の時などだ。最善を尽くすが。
下記に「rate limit」を避けるためのヒントをまとめる。あなたが提供しようとしているアプリケーションの内容によっては上記の制限では実現不可能であるかもしれない。もしもあなたのアプリケーションの狙いがリアルタイムな情報であれば下記を参照のこと。
The Streaming APIs
User streams
Site streams
APIの返答をあなたのアプリケーションやサイトに保存する。例えば、ページをロードする毎にAPIを叩くという処理は避ける。その代わりにローカルキャッシュにAPIの返答を保存し、ユーザーがページをリクエストした時にそのキャッシュをロードする。
もしたくさんのユーザーのトラッキングをする場合（例えばユーザの最新のステータスを裏で集めておく）などは、アクティブユーザーを優先的にトラックする。
もしあなたのアプリケーションが大量の検索結果を扱うのであれば、問い合わせの頻度を下げる。あるいは下記をフィルターして利用する。
The Streaming APIs
application-olnly認証はユーザー毎の制限とは独立している。その為、仮にあるユーザーのオペレーションが必要になった場合もapplication-only認証を利用して個別に解決することができる。
省略（悪さをするとブラックリストに載りますよ、という内容）
省略（詳しくは下記）
Streaming APIs documentation
省略（詳しくは下記）
https://dev.twitter.com/rest/public/rate-limits
Twitter API 「API Rate Limits」
https://dev.twitter.com/rest/public/rate-limiting
API Rate Limits
ユーザー毎またはアプリケーション毎
API ver. 1.1の「Rate Limit」はまずはユーザー毎、もっと正確に言うとユーザーの「access token」毎に認識される。
もしあるメソッドが１つの「Rate Limit」ウィンドウ毎に15リクエストを許可したら、効力のある「access token」毎に15のリクエストを許可するということになる。
これはAPI ver.1における、OAuthの効力がある間の「per-user/per-access token」の制限の方法と似ている。
もし「application-only authentication」を利用すると、「rate limit」はアプリケーション全体で維持される。
もしあるメソッドが「rate limit」ウィンドウ毎に15のリクエストを許可した場合、それはあなたのアプリケーションの代わりにウィンドウ毎に15のリクエストを許可することになる。これはユーザーごとの制限とは完全に別のものと認識されている。
15分ウィンドウ
API ver.1.1 の「rate limit」は15分のインターバルで区切られており、60分毎のブロックで扱っていたver.1.0からの変更である。加えて、すべての1.1のエンドポイントは認証が必要になるため、非認証によるコールと「rate limit」はもう存在しない。
API ver.1においてOAuthを利用できるアプリケーションは1時間毎、「access token」毎にGETベースのリクエストを３５０発生させることができたが、ver.1.1の「rate limit」モデルではメソッド毎のリクエスト制限によって幅広いリクエストを許可する。GETリクエストには次の２つの初期バケットが可能。
GETリクエスト：
15コール / 15分
180コール / 15分
参照→ https://dev.twitter.com/rest/public/rate-limits
検索
検索は15分に180の「rate limit」があるが、もしかしたら緩める可能性もある。検索に関してもver1.1では認証が必要であることに注意。
HTTP Headers and Response Codes
省略
GET、POSTリクエスト
「read」の「rate limit」はユーザー毎、アプリケーションごとに定義されている一方、
「write」の「rate limit」はユーザーレベルで単独に定義されている。
別の言い方をすると「read」の「rate limit」は下記のようなシナリオで認識される：
・ユーザーAがアプリケーションZを起動、ZがユーザーAのメンションタイムラインを１５分ウィンドウで１０回コールする。するとアプリケーションZはそのウィンドウでは５コールだけ残すことになる
・その後ユーザーAがアプリケーションXを起動、XがユーザーAのメンションタイムラインを３回コールする。この時アプリケーションXはこのウィンドウにおいて１２コール残すことになる。
・つまり、アプリケーションXの残りのコール数は同じユーザーAによる利用にもかかわらず、アプリケーションZのそれからは独立している。
これに比べて「write」はユーザー毎に定義されている。すなわち、もしユーザーAがアプリケーションZで５回のツイートをした場合、同じ期間においてAが開いた他のアプリケーション上においても５回のPOSTはカウントされることになる。
最後に、我々が返す「rate limit」には間違いがあるかも知れないし、ヘッダーを全く返さないこともあるかも知れない。恐らくキャッシュのリセットやキャッシュがビジー状態の時などだ。最善を尽くすが。
Rate Limitsを避ける為のヒント
下記に「rate limit」を避けるためのヒントをまとめる。あなたが提供しようとしているアプリケーションの内容によっては上記の制限では実現不可能であるかもしれない。もしもあなたのアプリケーションの狙いがリアルタイムな情報であれば下記を参照のこと。
The Streaming APIs
User streams
Site streams
キャッシュ
APIの返答をあなたのアプリケーションやサイトに保存する。例えば、ページをロードする毎にAPIを叩くという処理は避ける。その代わりにローカルキャッシュにAPIの返答を保存し、ユーザーがページをリクエストした時にそのキャッシュをロードする。
アクティブユーザのプライオリティ化
もしたくさんのユーザーのトラッキングをする場合（例えばユーザの最新のステータスを裏で集めておく）などは、アクティブユーザーを優先的にトラックする。
検索結果に適用
もしあなたのアプリケーションが大量の検索結果を扱うのであれば、問い合わせの頻度を下げる。あるいは下記をフィルターして利用する。
The Streaming APIs
application-only認証を「予約」として使う
application-olnly認証はユーザー毎の制限とは独立している。その為、仮にあるユーザーのオペレーションが必要になった場合もapplication-only認証を利用して個別に解決することができる。
ブラックリスト
省略（悪さをするとブラックリストに載りますよ、という内容）
Streaming API
省略（詳しくは下記）
Streaming APIs documentation
リソース毎の制限
省略（詳しくは下記）
https://dev.twitter.com/rest/public/rate-limits
