APIのレート制限
2種類
・ユーザー(アクセストークン)数単位
・アプリケーション単位
一覧表
・GET
公式doc
・Rate Limiting
・TwitterのAPI制限にかかった時の解決法
・TwitterAPIの制限について
・ユーザー(アクセストークン)数単位
・アプリケーション単位
一覧表
・GET
Endpoint | リクエスト回数 / 15分 user認証 | リクエスト回数 / 15分 app認証 |
---|---|---|
search/tweets | 180 | 450 |
・Rate Limiting
・TwitterのAPI制限にかかった時の解決法
・TwitterAPIの制限について
search/tweets
取得ツイート数
ツイート検索 取得できるツイート数の上限 / 1回
・100件
デフォルト
・15件
取得ツイート投稿日
期間制限
・指定された日付より前に作成されたツイートを返す
・検索インデックスには7日間の制限がある
・1週間以上経過したツイートを検索することは出来ない
Returns tweets created before the given date. Date should be formatted as YYYY-MM-DD. Keep in mind that the search index has a 7-day limit. In other words, no tweets will be found for a date older than one week.
ツイート取得リクエスト間隔
「Twitter Developers」へ登録したapp単位での認証
・リクエスト450回まで / 15分=900秒で
・サイトへ対して、15分間隔で450回以上アクセスがあればエラー発生
「連携アプリを認証」ボタンを押したuser単位での認証
・リクエスト180回まで / 15分=900秒で
・「連携アプリを認証」ボタンを押したuserが、15分間隔で180回以上アクセスすればエラー発生
・同一userが、平均で5秒間に1回以上ページ更新すればエラー発生
「ツイート取得リクエスト間隔」を考える
ツイートがメインのサービスではなく、メインコンテンツの補足としてツイートを表示する場合
・user単位で認証させることは難しい
app単位での認証
・複数ページでツイート取得する場合、各ページ毎にトークンを変えれば、各ページ単位で450回まで取得可能
→ 設置するページの数だけ、「Twitter Developers」でAPP登録する必要がある
→ 現実的ではない
対応案1
app単位で認証を行った後、取得結果をキャッシュ保存
・ツイートがメインのサービスではないため、そこまでリアル性は求めていない
(リアル性を求める場合は、ツイートがメインのサービスであろうと思われるため、user単位で認証すべき)
頻繁に使用すると思われる場合は、APIの応答結果をアプリケーションやサイトの内部に保存します。例えばウェブサイト上の全てのページで、表示されるたびに毎回Twitter APIを実行するのはやめてください。 そうはせずに、たまにAPIを実行して応答結果をローカルキャッシュに保存してください。ユーザーがウェブサイトを表示した時に保存されたレスポンス結果を読み込んでください。
・簡易キャッシュ
対応案2
一定間隔で取得したツイートをDB保存
・アクセスがある度にDB参照
対応案3
user単位で認証
・GET search/tweets