ユーザーが20のサッカーチームの最新のTwitterニュースを表示できるアプリを作成しようとしています。「アーセナル」などのサッカーチームのクエリでZend_Service_Twitter_Searchを使用しています。
私たちが抱えている問題は、ウェブサイトが20チームすべてのニュースを表示するリクエストを受け取っている可能性があるため、多くのユーザーがこれを行っている場合はAPIへの20回の呼び出しで、1時間あたりの制限に達する可能性があることです。
20チームすべての最新ニュースが必要なので、1分より長くデータをキャッシュしたくありません。誰かがこれについて私がドキュメントを読んだことについてアドバイスを持っていますが、そこに提案はありません。
乾杯
J
最近、似たようなものを実装しました。簡単な答えは、実行する必要のあるクエリの数を計算することです。チームごとに1つ、つまり一度に20としましょう。60秒（レート制限の期間）を（レート制限/クエリ数）で割り、その秒数の間、結果をmemcacheなどにキャッシュします。次に、ユーザーがサイトにアクセスしたときに、そこにある場合はmemcacheから結果をプルし、そうでない場合は結果を最新の状態にします。Memcacheは、期限切れのデータを自動的にクリアするという点で優れているため、レート制限を超えず、常に可能な限り最新のデータを取得できます（レート制限を破ることはありません）。
したがって、レート制限が1分あたり200である場合（そうではないことはわかっていますが、計算が簡単になります）、結果を60 /（200/20）=6秒間キャッシュします。したがって、最大レートでは、1分間に20チームごとに10クエリを実行するため、1分間に200クエリを実行します。これは、レート制限に相当します。
これは、バックエンドの設計上の問題のように思えます。対処したい問題は次のとおりです。
解決策は、データを永続化するためのある種のデータベース/データストアのようです。
毎分20回のAPI呼び出しを行って情報を保存し、ユーザーが好きなだけ利用できるようにすることができます。
Twitter APIのドキュメントを簡単に見てみると、データの保存に制限はないようです。検索APIの使用頻度を再検討することもできますが、制限は投稿されていません。