スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

TwitterのAPI利用制限 ver.1.1

下記のページの日本語訳。一部意訳も入っており、わかりにくい部分にはリンクや説明をつけました。

Twitter API 「API Rate Limits」
https://dev.twitter.com/rest/public/rate-limiting

API Rate Limits


ユーザー毎またはアプリケーション毎


API ver. 1.1の「Rate Limit」はまずはユーザー毎、もっと正確に言うとユーザーの「access token」毎に認識される。
もしあるメソッドが1つの「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ベースのリクエストを350発生させることができたが、ver.1.1の「rate limit」モデルではメソッド毎のリクエスト制限によって幅広いリクエストを許可する。GETリクエストには次の2つの初期バケットが可能。
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のメンションタイムラインを15分ウィンドウで10回コールする。するとアプリケーションZはそのウィンドウでは5コールだけ残すことになる

・その後ユーザーAがアプリケーションXを起動、XがユーザーAのメンションタイムラインを3回コールする。この時アプリケーションXはこのウィンドウにおいて12コール残すことになる。

・つまり、アプリケーションXの残りのコール数は同じユーザーAによる利用にもかかわらず、アプリケーションZのそれからは独立している。

これに比べて「write」はユーザー毎に定義されている。すなわち、もしユーザーAがアプリケーションZで5回のツイートをした場合、同じ期間においてAが開いた他のアプリケーション上においても5回の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

コメント

コメントの投稿

非公開コメント

PR

PR

プロフィール

何でも書くman

Author:何でも書くman
思ったことや備忘録など、とりあえずなんでも書きます。IT系のことや趣味、生活に関わることなども。

ページの先頭へ戻る
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。