Skip to main content

​
Ratenbegrenzungen

Alle RxScale APIs erzwingen Ratenbegrenzungen, um eine faire Nutzung und Systemstabilität zu gewährleisten. Die Limits gelten pro Sekunde — es gibt kein separates Kontingent pro Minute. Alle APIs verwenden dieselbe Drosselung, daher gelten die folgenden Regeln für jede von ihnen gleichermaßen; nur die Anzahl der Anfragen pro Sekunde unterscheidet sich.

​
Wie das Limit gezählt wird

Das Limit wird anhand der IP-Adresse des Clients ermittelt — niemals anhand Ihres API-Schlüssels, Ihrer Organisation oder Ihres Benutzers. Zwei API-Schlüssel, die von derselben ausgehenden IP aufrufen, teilen sich ein Budget, und derselbe API-Schlüssel erhält von zwei verschiedenen ausgehenden IPs zwei getrennte Budgets. Wenn mehrere Ihrer Systeme eine gemeinsame ausgehende IP verwenden (zum Beispiel hinter einem einzelnen NAT-Gateway), teilen sie sich ein einziges Budget.
Die Zähler der Ratenbegrenzung werden im Arbeitsspeicher jeder API-Serverinstanz gehalten, und jede API läuft auf mehreren automatisch skalierten Instanzen. Der von Ihnen beobachtete effektive Durchsatz kann daher etwas höher als das dokumentierte Limit liegen, da sich Ihre Anfragen auf mehrere Instanzen verteilen können. Betrachten Sie die dokumentierten Anfragen pro Sekunde pro IP als das garantierte Budget, für das Sie Ihre Integration auslegen sollten — verlassen Sie sich nicht auf den zusätzlichen Spielraum, da dieser von der Verteilung des Traffics abhängt.

​
Limit pro API

Die Limits werden pro API konfiguriert und können sich ändern. Wenn Ihre Integration ein höheres Limit benötigt, kontaktieren Sie Ihren RxScale-Kundenbetreuer.

​
Antwort bei Ratenbegrenzung

Wenn Sie das Ratenlimit überschreiten, gibt die API 429 Too Many Requests zurück.
Dies ist die einzige RxScale-Fehlerantwort, die kein JSON ist. Eine gedrosselte Anfrage liefert Content-Type: text/html mit einer kurzen HTML-Fehlerseite — response.json() löst hier also eine Ausnahme aus. Verzweigen Sie über den Statuscode, nicht über den Antwortkörper.
Es werden weder ein Retry-After- noch X-RateLimit-*-Header gesendet. Da das Zeitfenster fest eine Sekunde beträgt, genügt eine Wartezeit von einer Sekunde für ein neues Kontingent — siehe Bewährte Praktiken weiter unten.

​
Maximale Anfragegröße

Alle RxScale APIs begrenzen zusätzlich die Größe eines einzelnen Anfragekörpers. Eine größere Anfrage wird abgelehnt, bevor sie verarbeitet wird, mit 413 Content Too Large:
JSON-Anfragen liegen im Normalbetrieb weit unter diesem Limit. Wenn Sie einen sehr großen Stapel senden, verteilen Sie ihn auf mehrere Anfragen, statt eine einzelne Anfrage wachsen zu lassen — siehe Fassen Sie Operationen zusammen weiter unten.

​
Bewährte Praktiken

  • Verwenden Sie Webhooks anstelle von Polling für Echtzeit-Updates. Registrieren Sie Webhook-Abonnements, um Benachrichtigungen zu erhalten, wenn sich Bestellungen oder Lagerbestände ändern.
  • Cachen Sie Antworten wo es sinnvoll ist. Produktkataloge und SKU-Listen ändern sich selten.
  • Warten Sie nach einem 429. Warten Sie mindestens eine Sekunde — ein volles Zeitfenster — vor dem ersten erneuten Versuch und erhöhen Sie die Wartezeit, wenn Sie weiterhin gedrosselt werden. Wiederholen Sie die Anfrage niemals sofort in einer engen Schleife.
  • Prüfen Sie den Statuscode, bevor Sie den Antwortkörper parsen. Ein 429 ist HTML — Code, der immer response.json() aufruft, scheitert also genau an der Antwort, für die er geschrieben wurde.
  • Verteilen Sie Massenverarbeitungen über die Zeit, statt einen Schwall zu senden. Alle Ihre Systeme hinter einer ausgehenden IP teilen sich ein einziges Budget.
  • Fassen Sie Operationen zusammen, wenn möglich, anstatt für jedes Element einzelne Anfragen zu senden.