Rate Limit

Anbieter setzen Limits aus einfachen Gründen. Kapazität ist endlich und geteilt, und ein außer Kontrolle geratenes Skript soll nicht alle anderen ausbremsen. Limits begrenzen auch Kosten und bremsen Missbrauch, etwa einen gestohlenen Schlüssel, mit dem ein Dienst überflutet wird. Ohne sie könnte ein Fehler in einer Schleife tausende Aufrufe in einer Minute senden. Stell dir eine Bäckerei mit Schlange vor: Wenn ein Kunde in der ersten Minute alle Brote kauft, ist das unfair gegenüber den anderen, also begrenzt der Bäcker jeden, und ein gutes Limit ist nur ein fairer Anteil als Zahl.

Limits gibt es in mehreren Formen. Ein kurzes pro Minute fängt Spitzen ab. Ein längeres, pro Tag, begrenzt die Gesamtnutzung, entweder als festes Fenster, das zu einer bestimmten Uhrzeit zurückgesetzt wird, oder als gleitendes Fenster, das immer auf den zurückliegenden Zeitraum schaut. Manche Dienste zählen Anfragen, andere Tokens, und einige begrenzen zusätzlich, wie viele Aufrufe gleichzeitig laufen dürfen. Oft hängen Limits vom Tarif ab: Eine höhere Stufe bekommt eine höhere Decke.

Mit einem Limit gut umzugehen ist ein kleines Handwerk. Lies den Header Retry-After, wenn er vorhanden ist, und warte so lange. Sonst versuche es erneut mit exponentiellem Backoff und etwas Zufall, nie in einer engen Schleife. Verringere die Zahl der Aufrufe durch Zwischenspeichern von Antworten und Bündeln von Arbeit, und verteile die Last über die Zeit. Und denk daran: Ein Rate Limit ist kein Ausgabenlimit. Ein leeres Guthaben ist ein anderer Fehler mit anderer Abhilfe. Bibliotheken kapseln diese Logik oft für dich, versuchen höflich erneut und legen Pausen ein; schreibst du einen eigenen Client, protokolliere jedes 429 mit Zeitstempel, um zu sehen, ob Spitzen oder dauerhafte Last es auslösen.

Die Dokumentation der NeverNo-API legt die Regel fest. Jedes Konto hat je nach Tarif eine Anzahl von API-Anfragen pro gleitenden 24 Stunden. Darüber hinaus erhalten Aufrufe ein 429 mit dem Code rate_limited, bis das Fenster weiterrückt. Zusätzlich gilt ein kurzes Limit pro Minute, und dann kommt das 429 mit einem Retry-After-Header. Jeder Aufruf zählt als eine Anfrage, gleich wie viele Tokens oder Bilder, während der Endpunkt zum Zählen von Tokens nicht zählt. Weil das Fenster gleitet, kehrt Kapazität allmählich zurück, wenn alte Aufrufe verfallen, und nicht schlagartig um Mitternacht.

Die genauen Zahlen je Tarif stehen in der Tabelle der API-Dokumentation, und wir wiederholen sie hier nicht, damit diese Seite nie veraltet. Leere Credits sind ein anderer Fall: Die API antwortet mit 402 und insufficient_credits. Das Dev-Abo verwendet das Anfragelimit von Pro+. Da die Dokumentation die einzige Quelle der Zahlen ist, sollte ein Skript die Obergrenze dort lesen statt sie zu raten und einen plötzlichen Anstieg von 429-Fehlern als Signal werten, langsamer zu werden und Arbeit einzureihen.