要求されたデータが多すぎる場合のHTTP要求に対する適切な応答
広告キャンペーンのトラッカーデータをリクエストできるようにする広告配信プラットフォーム用のAPIを構築しています。多くの場合、キャンペーンは数億のリクエストを超えるため、テラバイトに相当するデータが大量に存在することになります。そのため、APIコンシューマーが一度に大量のデータを要求しないように（要求がタイムアウトするなど）防止する必要がありますが、それを行うためのベストプラクティスが何かはわかりません。
既に特定したオプションは次のとおりです：
- データのどのセクションが必要かを示す追加のパラメーターをリクエストに追加する
- データを切り捨てて、クライアントに、より具体的なフィルターを使用する必要があることを伝える
- hTTPステータスコード413で応答します（ただし、これは応答ではなく、大きなリクエスト本文のようです）
- ストリーミングAPIへの切り替え（例 TwitterのストリーミングAPI ）
しかし、私の質問は、この種の状況に対する標準的な実践/適切な対応は何ですか？
注：DoS攻撃はパブリックAPIではないため、それほど心配する必要はありません。
リクエストの形式が正しくない場合に発生する可能性のある、最も過酷で友好的でない結果を返します（測定が許可するよりも多くのデータを返すリクエストは、形式が正しくありません）。 4 **エラーコードを返すことをお勧めします。次に、ページングパラメータも提供して、ユーザーがページをリクエストできるようにします。たとえば、oDataにはこの機能があります。いかなる状況でも、サイレントにデータを切り捨てないでください。
顧客との相談は悪い考えです。彼らは、エラーを最小限に抑えるために可能なことは何でもするように指示しますが、これは悪いエンジニアリングアプローチです。これはあなたの決定です。
ページ分割されたapiの例はoDataです。
http://www.odata.org/documentation/odata-version-2-0/uri-conventions/
@ joshin4coloursの発言をさらに詳しく説明すると、誤った二分法（三分法？）があると思います。 3つのソリューションすべてを提供しないのはなぜですか？多分デフォルトは413を返すことですが、他のフラグを使用すると、データに埋め込まれたエラーで必要なものを取得したり、データをバッチ処理する方法を提供したりできます。
それは実際に、APIの特定の顧客/消費者が何を期待しているか、そしてAPIをどのように使用したいかに依存します。彼らはこれまでに413を望んでいるのでしょうか？デフォルトの応答にはいくつかのデータが含まれ、さらにいくらあるかを示す必要がありますか？多分。また、クライアントの立場に立って、クライアントが何を望むか、つまり何が役立つかについて考えることもできます。
私が通常行っているのは、データの最初のバッチに、それ以上のデータを与えることです。 413を返すのはあまり友好的ではありませんが、場合によってはそれが必要なこともあります。私が経験したことから、通常はデフォルトのバッチサイズがありますが、人々は特定のバッチサイズを上限まで求めることができます。
また、バッチサイズを減らすために、集計またはサンプリングを検討することもできます。たとえば、5,000,000件の一致するレコードのランダムサンプルとして50,000件の結果が必要です。結果をどの程度統計的に有意にしたいかに応じて、スライスとダイスを行う方法はいくつかあります。
ベストプラクティスについては不明ですが、私たちの場合、APIにある種の最大値に設定されたパラメーターがあります（JavaのInteger.MAX_VALUEを考えてください）。これらのパラメーターは、多くの場合、アプリケーションのUI /クライアント側では使用できず、サーバー側の呼び出しでのみ使用できます。
基本的に、アプローチは、リクエストによって返されるレコードに最大値を設定することです。特に、データを整理したりページ番号を付けたりする必要がない場合は、うまく機能するようです。
クライアント（人間など）がこの最大値を超える必要がある場合は、クライアントを増やすか、何らかの方法でデータをバッチ処理することを検討してください。