Rate Limiting
Die API begrenzt Anfragen mit einem Leaky-Bucket-Algorithmus. Jede Anfrage kostet eine bestimmte Anzahl von Einheiten, und diese Einheiten laufen mit konstanter Rate aus dem Eimer ab. So fließt der Datenverkehr gleichmäßig, während kurze Spitzen weiterhin möglich sind.
GraphQL-API
Das Rate Limiting der GraphQL-API basiert auf den Kosten jeder Anfrage statt auf einer festen Anzahl von Anfragen. Die folgenden Abschnitte behandeln bewährte Vorgehensweisen, um diese Kosten niedrig zu halten, und wie Sie Ihren aktuellen Rate-Limit-Status auslesen.
Bewährte Vorgehensweisen
- Verwenden Sie Subscriptions statt Polling mit Queries, um zu erfahren, wann sich Daten ändern.
- Fragen Sie nur die Felder ab, die Sie benötigen, und grenzen Sie Listen-Queries mit
filterein. - Listen-Queries geben bis zu 100 Datensätze pro Seite zurück, aber eine größere Seite kostet mehr als eine kleinere. 100 Datensätze in einer Anfrage abzurufen kostet mehr als 10, fordern Sie also lieber weniger Datensätze an. Details finden Sie unter Pagination.
- Wird eine Anfrage mit dem Fehler
429abgelehnt, ist Ihr Eimer voll. Senden Sie keine Anfragen mehr und stellen Sie neue Anfragen erst, wenn die durchresetangegebene Zeit verstrichen ist.
Rate Limit
Um die API vor zu komplexen oder ressourcenintensiven Queries zu schützen, werden jeder Anfrage Kosten zugewiesen, die sich nach der Menge der angeforderten Daten richten. Jede Antwort auf eine gültige Anfrage oder auf eine Anfrage, die an der Geschäftsvalidierung scheitert, enthält ein Objekt extensions.cost mit den Kosten der Anfrage und dem Stand Ihres Rate Limits. Es entfällt vollständig, wenn eine Anfrage an der GraphQL-Schemavalidierung scheitert.
cost· Integer- Die Kosten der aktuellen Anfrage in Einheiten.
limit· Integer- Die maximalen Kosten in Einheiten, die im aktuellen Rate-Limit-Fenster zulässig sind.
used· Integer- Wie viele Einheiten in diesem Fenster bereits verbraucht wurden.
remaining· Integer- Wie viele Einheiten Ihnen noch zur Verfügung stehen, bevor das Limit erreicht ist.
reset· Integer- Ein UNIX-Zeitstempel in Sekunden, der angibt, wann das Kontingent erneuert wird.
REST-API
Das Rate Limiting der REST-API gilt für den Tile-Service. Anders als bei der GraphQL-API wird der Rate-Limit-Status über HTTP-Antwort-Header zurückgegeben, und jede Anfrage kostet pauschal 1 Einheit. Diese Header werden bei jeder Anfrage zurückgegeben, auch bei fehlgeschlagenen.
x-ratelimit-cost· Integer- Die Kosten der aktuellen Anfrage in Einheiten. Bei REST-Anfragen immer
1. x-ratelimit-limit· Integer- Die maximalen Kosten in Einheiten, die im aktuellen Rate-Limit-Fenster zulässig sind.
x-ratelimit-used· Integer- Wie viele Einheiten in diesem Fenster bereits verbraucht wurden.
x-ratelimit-remaining· Integer- Wie viele Einheiten Ihnen noch zur Verfügung stehen, bevor das Limit erreicht ist.
x-ratelimit-reset· Integer- Ein UNIX-Zeitstempel in Sekunden, der angibt, wann das Kontingent erneuert wird.
Aktuelle Limits
Rate Limits gelten pro Kunde in einem Fenster von einer Minute. Ein Standardlimit gibt es noch nicht. Limits werden individuell pro Kunde konfiguriert, bis 2027 Standardlimits eingeführt werden.
Einige Queries und Mutations haben zusätzlich eigene Limits, die niedriger sind als Ihr Gesamtlimit. Diese werden pro Produkt und teilweise pro Anfrage festgelegt, nicht global.
War dieser Inhalt hilfreich?