/v1-API erzwingt zwei voneinander unabhängige Anfragekontingente. Eine Anfrage wird
abgelehnt, wenn eines der beiden Kontingente erschöpft ist.
Das Kontingent pro Schlüssel folgt dem Schlüssel überallhin, wo er verwendet wird. Das Kontingent pro IP-Adresse
ist das einzige Kontingent für nicht authentifizierten Datenverkehr und eine zweite Obergrenze für
authentifizierten Datenverkehr.
Die Begrenzungen werden vor der Authentifizierung durchgesetzt, sodass auch Anfragen mit ungültigen oder
fehlenden Anmeldedaten auf das Kontingent der Quelle angerechnet werden. Die genauen numerischen
Kontingente werden vom Betreiber konfiguriert und können sich ändern; der unten beschriebene Antwortvertrag
ist die stabile Schnittstelle, auf der Sie aufbauen sollten.
apikey:secret oder secret:).
Setzen Sie BASE auf den regionalen Host der Organisation – siehe
Regionen.
Die 429-Antwort
Wenn ein Kontingent erschöpft ist, gibt die API429 Too Many Requests mit einem
Retry-After-Header (in Sekunden) und dem standardmäßigen Problem-Details-Body zurück:
429 Too Many Requests
429
gleich: warten und dann erneut versuchen.
429-Antworten behandeln
1
Retry-After beachten
Warten Sie mindestens so viele Sekunden, wie im
Retry-After-Header angegeben sind, bevor Sie
es erneut versuchen. Ein früherer erneuter Versuch verbraucht nur erneut Kontingent für Anfragen, die
abgelehnt werden.2
Bei wiederholten Fehlern exponentiell zurückweichen
Wird ein erneuter Versuch wieder abgelehnt, verlängern Sie Ihre Wartezeit (Backoff) und fügen Sie zufälligen Jitter hinzu,
damit parallele Worker nicht im Gleichschritt erneut senden. Kürzen Sie niemals den
Retry-After des Servers, um ihn an eine lokale
Obergrenze anzupassen. Wenn der Server Sie auffordert, länger zu warten, als Ihr Kontingent für erneute Versuche erlaubt,
brechen Sie ab und planen Sie die Aufgabe für einen späteren Zeitpunkt ein.3
Anfragerate glätten
Bevorzugen Sie eine gleichmäßige Anfragerate gegenüber Lastspitzen. Verwenden Sie bei Massenabfragen die maximale
Seitengröße (
limit=500), um die Sammlung mit weniger Anfragen abzudecken – siehe
Paginierung. Wenn mehrere Listenabfragen parallel
laufen (zum Beispiel Power-BI-Tabellen), halten Sie die Parallelität moderat und beachten Sie
Retry-After, damit eine vorübergehende 429-Antwort nicht die gesamte Aktualisierung scheitern lässt.429-Antworten bei einer GET-Anfrage, mit höchstens
fünf Versuchen und höchstens 60 Sekunden Wartezeit zwischen den Versuchen. Bei anderen Fehlern bricht es
sofort ab. Netzwerk-Timeouts werden an den Aufrufer weitergegeben. Konfigurieren Sie
Timeouts und Kontingente für erneute Versuche passend zu Ihrer Arbeitslast. requests interpretiert das Lese-Timeout
als maximale Leerlaufzeit beim Empfang von Daten, nicht als Gesamtfrist.
Laden Sie LIVING_SECURITY_API_KEY aus Ihrem Secret Manager. Installieren Sie requests,
bevor Sie dieses Beispiel ausführen. Rufen Sie get_with_retry("/organization") auf, um es zu verwenden.
Python
Empfohlener Aktualisierungsplan
Dimensionieren Sie die Aktualisierungshäufigkeit anhand Ihres Schlüsselkontingents und der Seitengröße. Ein vollständiger historischer Ladevorgang einer großen Sammlung ist ein einmaliger Aufwand; bevorzugen Sie für regelmäßige Aktualisierungen im laufenden Betrieb inkrementelle Zeitfenster, damit jeder Lauf deutlich unter dem Kontingent bleibt. Legen Sielimit=500 immer explizit fest – der Standardwert von 25 vervielfacht die Anzahl der Anfragen.
