Richtige Antwort auf HTTP-Anfrage, wenn zu viele Daten angefordert werden

Ich erstelle eine API für eine Adserving-Plattform, mit der Sie Trackerdaten für Werbekampagnen anfordern können. Kampagnen überschreiten häufig Hunderte Millionen Anfragen, was bedeutet, dass Daten im Wert von vielen Terabyte vorliegen. Daher müssen wir verhindern, dass API-Konsumenten zu viele Daten gleichzeitig anfordern (so dass die Anforderung abgelaufen ist), aber ich bin mir nicht sicher, wie dies am besten funktioniert.

Optionen, die ich bereits identifiziert habe, sind:

1. Fügen Sie der Anforderung einen zusätzlichen Parameter hinzu, der angibt, welcher Abschnitt der Daten gewünscht wird
2. Schneiden Sie die Daten ab und teilen Sie dem Client irgendwie mit, dass er spezifischere Filter verwenden muss
3. Antworten Sie mit dem HTTP-Statuscode 413 (dies scheint jedoch für große Anforderungskörper zu gelten, nicht für Antworten).
4. Wechseln zu einer Streaming-API (wie die Streaming-APIs von Twitter )

Aber meine Frage ist, was ist die Standardpraxis / richtige Antwort für diese Art von Situation?

Hinweis: DoS-Angriffe sind kein großes Problem, da dies keine öffentliche API ist

Geben Sie das härteste und unfreundlichste Ergebnis zurück, das im Falle einer fehlerhaften Anforderung möglich ist (eines, das mehr Daten zurückgibt, als Ihre Messung zulässt, ist fehlerhaft). Ich schlage vor, einen 4 ** Fehlercode zurückzugeben. Geben Sie dann auch Paging-Parameter an, damit Benutzer Seiten anfordern können. oData verfügt beispielsweise über diese Funktion. Schneiden Sie die Daten unter keinen Umständen stillschweigend ab.

Kundenberatung ist eine schlechte Idee. Sie werden Ihnen sagen, dass Sie alles tun sollen, um Fehler zu minimieren, was ein schlechter technischer Ansatz ist. Dies ist Ihre Entscheidung, nehmen Sie sie bei den Hörnern und tun Sie das Richtige.

Ein Beispiel für eine paginierte API ist oData:

http://www.odata.org/documentation/odata-version-2-0/uri-conventions/

Um zu erweitern, was @ joshin4colours gesagt hat, denke ich, dass Sie eine falsche Dichotomie (Trichotomie?) Haben. Warum nicht alle drei Lösungen anbieten? Möglicherweise wird standardmäßig ein 413 zurückgegeben, aber mit anderen Flags können Sie entweder mit einem eingebetteten Fehler in den Daten etwas von dem bekommen, was Sie wollen, und / oder eine Möglichkeit zum Stapeln der Daten bereitstellen.

Es hängt wirklich davon ab, was Ihr spezifischer Kunde / Verbraucher der API erwartet und wie er Ihre API verwenden möchte. Wollen sie jemals einen 413? Sollte die Standardantwort einige Daten enthalten und angeben, wie viel mehr vorhanden ist? Könnte sein. Sie könnten sich auch in die Lage des Kunden versetzen und darüber nachdenken, was er möchte, dh was für ihn nützlich wäre.

Was ich normalerweise getan habe, ist, den ersten Datenstapel mit einer Vorstellung davon zu geben, wie viel mehr es gibt. Die Rückgabe eines 413 ist nicht sehr freundlich, aber vielleicht möchten Sie das in einigen Fällen. Nach meinen Erfahrungen gibt es normalerweise eine Standard-Stapelgröße, aber die Leute können bis zu einem gewissen Grenzwert nach einer bestimmten Stapelgröße fragen.

Sie können auch eine Aggregation oder Probenahme in Betracht ziehen, um die Chargengröße zu verringern. Zum Beispiel möchte ich 50.000 Ergebnisse als Zufallsstichprobe von 5.000.000 übereinstimmenden Datensätzen. Es gibt verschiedene Möglichkeiten, in Scheiben zu schneiden und zu würfeln, je nachdem, wie statistisch signifikant Ihre Ergebnisse sein sollen.

Wir sind uns über eine bewährte Methode nicht sicher, aber in unserem Fall haben wir Parameter in unserer API, die auf einen Maximalwert festgelegt sind (denken Sie an Integer.MAX_VALUE aus Java). Diese Parameter sind häufig nicht für die Benutzeroberfläche / Client-Seite der Anwendung verfügbar, sondern nur für serverseitige Aufrufe.

Grundsätzlich besteht der Ansatz darin, ein Maximum für Datensätze festzulegen, die von Ihrer Anfrage zurückgegeben werden. Scheint gut zu funktionieren, insbesondere wenn Daten in keiner Weise organisiert oder paginiert werden müssen.

Wenn ein Client (menschlich oder anderweitig) mehr als dieses Maximum benötigt, sollten Sie in Betracht ziehen, es zu erhöhen oder Ihre Daten irgendwie zu stapeln.