ウェブリクエストを抑制する責任は誰にありますか？

Question

私は、サードパーティのWebサイトから情報を取得するクラスライブラリに取り組んでいます。設定された時間内にリクエストが多すぎると（〜0.5秒）、アクセスされているWebサイトが応答を停止します。

私のライブラリのパブリックメソッドは、Webサーバー上のファイルに直接関連しています。つまり、メソッドが呼び出されるたびにHttpWebRequestが作成され、サーバーに送信されます。すべてがうまくいくと、XMLファイルが呼び出し元に返されます。ただし、これが0.5秒未満で2番目のWeb要求である場合、の要求はタイムアウトになります。

私のジレンマは、リクエストスロットルをどのように処理するべきかにあります。明らかに、私は、呼び出し側が応答を待つことを避けたいと思っています。特に、要求がタイムアウトすることを完全に確信している場合は特にそうです。

私のライブラリが作成したWeb要求を待ち行列に入れてスロットルするのが理にかなっていますか？クライアントがAPI呼び出しの間に十分長く待たなければライブラリは単に例外をスローするべきですか？

Answer 1

ライブラリの概念は、クライアントコードをできるだけ心配する必要がないようにすることです。したがって、私は要求を待ち行列に入れ、タイムリーに結果を返すためにライブラリの仕事にします。理想的な世界では、クライアントコードがUIをブロックするのではなく非同期で動作できるように、コールバックまたはデリゲートモデルを使用します。また、キューをスキップするオプションを提供することもできます（また、あまりにも早く動作する場合は失敗する）可能性があり、場合によってはキューモデル内で優先順位を提供することもできます。

私はまた、良い市民であることをデフォルトにし、図書館のデフォルトの操作がデータ提供者の条件に従うことは、図書館の作者の責任であると考えています。

Answer 2

これはWebサーバーの責任です。クリティカルな負荷はハードウェア、ネットワーク帯域幅などアプリケーションの制御範囲外の多くに依存するため、それを処理しようとする必要はありません。 IISは、さまざまな構成オプションに基づいてトラフィックを抑制できます。

Answer 3

私は2つの独立したシステムを扱っており、どちらも過度の負荷から自分自身を守るための対策を講じるべきだと言いたいと思います。 Webサーバーは着信接続を拒否し、クライアント・ライブラリーは、外部サービスの応答が遅い、または応答が遅い要求を減らすための手順を実行する必要があります。クライアント上でこれを処理するための一般的なパターンは、呼び出しを外部サービスにラップし、失敗後一定期間高速で失敗する 'サーキットブレーカ'です。

Answer 4

どのようなクライアントですか？これはインタラクティブなクライアントですか、例えば：GUIベースのアプリですか？

この場合、Webブラウザシナリオと同じにして、タイムアウトサーフェスを呼び出し元に任せることができます。また、このWebサーバーが要求を抑制していることがわかっている場合は、クライアントに再試行の前に一定の時間待機する必要があることを伝えることができます。このようにして、クライアントは要求を再発行し続けることはなく、最初のタイムアウトが発生したときに、要求をあまりに速く発行するのは無駄だと分かります。