流行ってますよね、Twitter。
ちょっくらWebサービスでも・・ということで、色々検索してみますが、やはり公式リファレンスにかなうものはありません。
ということで、現時点での最新の内容をまとめておきます。
どういうものがあるかは過去に書きました。
今回は、開発者が気になるリクエストの回数とか、規制とかそういうところを。
このページをまるごと意訳してみます。
APIの制限について
- 認証が必要なもの
- 認証が不要のもの
それらによって、取得できる内容が違ってきます。
そりゃもちろん、認証なしにDMとか見れたり、つぶやけたらまずいですもんね、納得。
ただ区分けはこれだけではなくて、APIの呼び出しに制限：規制がかかってきます。
- 呼び出し回数に制限があるもの
- 呼び出し回数に制限のないもの
ほとんどのAPIは前者、呼び出し回数に制限があります。
唯一の後者が、検索APIです。
※正確には、呼び出し回数での制限がないです。
検索するキーワードの複雑さ具合によっては、呼び出しに失敗します。
肝心の規制について
REST API Rate Limiting
The default rate limit for calls to the REST API varies depending on the authorization method being used and whether the method itself requires authentication.
・Unauthenticated calls are permitted 150 requests per hour. Unauthenticated calls are measured against the public facing IP of the server or device making the request.
・OAuth calls are permitted 350 requests per hour and are measured against the oauth_token used in the request.
意訳：
REST APIの呼び出し回数に関する制限は、認証の有無など条件によって変わってくる。
・認証なし呼び出しの場合は、150回/時間まで。
これはリクエストを行ったサーバーのIPでカウントされる。
・認証あり呼び出しの場合は、350回/時間まで。
こっちはリクエストを行ったトークン(認証したユーザー)でのカウントになる。
認証ありなら350枚、なしなら150枚のチケットをもらえて、それを使っていく、と。
なくなったらその1時間は遊べません！と。
Search API
ここがややこしい。
Some features, such as the GET search method, have additional feature rate limits which are applied in conjunction with the main REST API rate limit. Calls to users/search will count against both the feature and default request rate limit. If either limit is exhausted, the method will fail. You can monitor the status of the feature rate limit by inspecting the HTTP response headers that are returned.
意訳：
Search APIなど幾つかのものには、他のREST APIの制限と一緒にカウントされるものもあります。
ユーザー検索APIの場合、それとは別に、通常のREST APIも呼んだとみなされます。
どっちかのカウントでもなくなると、呼び出しに失敗します。
つまり・・・？
基本的な認証なしAPI呼び出しの場合、IP単位で150回/時の呼び出しが可能。
ただ、検索系のAPIは呼び出し回数に制限がないが、呼び出し時にはそのIPが本来もっている150回分のチケットがあるかどうかを確認される。
もしそのチケットがなかった場合、回数制限のない検索APIといえども失敗する。
（ってことかしら？多分そう。
先ほど、検索APIだけは回数制限なしと書きましたが、半分本当で半分嘘でしたね。
ちなみに、users/search APIは、60回/時という制限がついてるそうな。
Search APIの制限について
Requests to the Search API, hosted on search.twitter.com, do not count towards the REST API limit. However, all requests coming from an IP address are applied to a Search Rate Limit. The Search Rate Limit isn't made public to discourage unnecessary search usage and abuse, but it is higher than the REST Rate Limit. We feel the Search Rate Limit is both liberal and sufficient for most applications and know that many application vendors have found it suitable for their needs.
意訳：
検索APIは、RESTチケットを使わずに呼び出せます。
というか、実はTwitterAPIに向かってくるリクエストは全部まとめて数えられてて、実は一定の値で制限してます。
基本的には青天井と思ってて構わんけど、無駄遣いはやめてほしい。
まぁ、普通に使う分には困らない回数にしてあるから安心しなさい、と。
他の注意
Search API usage requires that applications include a unique and identifying User Agent string. An HTTP Referrer is expected but is not required. Applications using the Search API but failing to include a User Agent string will receive a lower rate limit.
意訳：
検索APIといえど、リクエストするときにはUserAgentをつけて欲しい。
それがないと、ある場合に比べて少ない回数でも例の青天井リミットに規制されるかもしれません、だそうな。
その他書いてあること。
- ホワイトリストは今のところないよ（表向きには
- めっちゃ検索するつもりなら、StreamingAPIを使ってください
- キャッシュするとか、検索クエリに日付を入れて必要な分だけ取得するとか、そういう思いやりが大事
- ブラックリストに入れられるケースはもちろんあるのでお気をつけて。