サードパーティのWebサイトから情報を取得するクラスライブラリに取り組んでいます。設定された時間（〜0.5秒）内に要求が多すぎると、アクセスされているWebサイトは応答を停止します。
私のライブラリのパブリックメソッドは、Webサーバー上のファイルのリソースに直接関連しています。つまり、メソッドが呼び出されるたびに、anHttpWebRequestが作成され、サーバーに送信されます。すべてがうまくいけば、XMLファイルが呼び出し元に返されます。ただし、これが0.5秒未満の2番目のWebリクエストである場合、リクエストはタイムアウトになります。
私のジレンマは、リクエストのスロットリングをどのように処理するか（あるとしても）にあります。明らかに、私は発信者が応答を待っていることを望んでいません-特に彼らの要求がタイムアウトすることを完全に確信している場合は。
私のライブラリが作成したWebリクエストをキューに入れて調整する方が理にかなっていますか、それともクライアントがAPI呼び出しの間に十分な時間待機しない場合、ライブラリは単に例外をスローする必要がありますか？
ライブラリの概念は、クライアントコードにできるだけ心配することを少なくすることです。したがって、リクエストをキューに入れて結果をタイムリーに返すことをライブラリの仕事にします。理想的な世界では、コールバックまたはデリゲートモデルを使用して、クライアントコードがUIをブロックせずに非同期で動作できるようにします。また、キューをスキップするオプション（および、動作が早すぎる場合は失敗する）を提供したり、キューモデル内で優先順位を提供したりすることもできます。
私はまた、図書館の作者がデフォルトで善良な市民になること、そして図書館のデフォルトの運営がデータ提供者の条件に従うことであると信じています。
私は両方とも言うでしょう-あなたは2つの独立したシステムを扱っており、両方とも過度の負荷から身を守るための対策を講じる必要があります。Webサーバーは着信接続を拒否する必要があり、クライアントライブラリは、低速または応答のない外部サービスへの要求を減らすための手順を実行する必要があります。クライアントでこれを処理するための一般的なパターンは、外部サービスへの呼び出しをラップする「サーキットブレーカー」であり、障害が発生した後、一定期間高速に障害が発生します。
それがWebサーバーの責任です、imo。重要な負荷は、ハードウェア、ネットワーク帯域幅など、アプリケーションの制御の及ばない多くのものに依存するため、それを処理しようとすること自体に関係する必要はありません。IISは、さまざまな構成オプションに基づいてトラフィックを制限できます。
どんなクライアントですか？これはインタラクティブなクライアントですか？例：GUIベースのアプリですか？
その場合、それをWebブラウザーのシナリオと同一視して、タイムアウトを呼び出し元に表示させることができます。また、このWebサーバーが要求を抑制していることが確実にわかっている場合は、再試行する前に、指定された期間待機する必要があることをクライアントに通知できます。このようにして、クライアントはリクエストの再発行を継続せず、最初のタイムアウトが発生したときに、リクエストの発行が速すぎるのは無駄であることを認識します。