要求されたデータが多すぎる場合のHTTP要求に対する適切な応答

広告キャンペーンのトラッカーデータをリクエストできる広告配信プラットフォーム用のAPIを構築しています。多くの場合、キャンペーンは数億のリクエストを超えるため、テラバイトに相当するデータが大量に存在します。したがって、APIの利用者が一度に大量のデータをリクエストすること（リクエストがタイムアウトするなど）を防ぐ必要がありますが、それを行うためのベストプラクティスが何かはわかりません。

私がすでに特定したオプションは次のとおりです。

1. データのどのセクションが必要かを示す追加のパラメーターをリクエストに追加する
2. データを切り捨て、どういうわけか、より具体的なフィルターを使用する必要があることをクライアントに伝えます
3. HTTPステータスコード413で応答します（ただし、これは応答ではなく、大きなリクエスト本文のようです）
4. ストリーミング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 /クライアント側では使用できず、サーバー側の呼び出しでのみ使用できます。

基本的に、アプローチは、リクエストによって返されるレコードに最大値を設定することです。特にデータを整理したりページ番号を付けたりする必要がない場合は、うまく機能しているようです。

クライアント（人間など）がこの最大値を超える必要がある場合は、クライアントを増やすか、何らかの方法でデータをバッチ処理することを検討してください。