Zur Sicherung eines API gehört neben den Themen Authorisierung und Authentifizierung, dass man gewisse SLAs (Service Level Agreements) – egal ob nun selbst bestimmt oder durch Partner – einhalten kann. Schon früh war uns klar, dass wir nicht einfach jedem unserer API-Nutzer erlauben konnten, so viele Request wie möglich gegen unsere Schnittstelle senden zu dürfen. So starteten wir das shipcloud API seinerzeit mit harten API Request Limits, welche wir ziemlich lange, genauer gesagt bis vor wenigen Wochen, beibehalten haben.

Request Limits sind einfach und effizient, denn sie stellen – wie in unserem Fall – sicher, dass ein Nutzer nur eine bestimmte Anzahl an Requests machen darf und dann endet die Nutzung für diesen Account. Doch immer wieder stießen wir an die Grenzen dieses Ansatzes. Zum Einen war es schwer Nutzern die technisch nicht so versiert sind zu erklären, was ein API-Limit ist, wenn sie doch einfach nur ein Plugin oder eine Integration nutzen und keinen Einfluss auf die „Hungrigkeit“ ihrer Anbindung haben. Zum Anderen gab es keine Möglichkeit, Limits kontinuierlich auf die jeweiligen Gegebenheiten einzelner oder mehrerer Nutzer anzupassen. So stießen unsere Kunden im starken Weihnachtsgeschäft selbstverständlich an ihre Limits und urplötzlich stand der Versand still, da es keine Möglichkeit gab, proaktiv zu erkennen, dass man ein Problem aufgrund des gestiegenen Auftragsvolumens bekommen könnte.

Hinzu kommt, dass wir als SaaS-Anbieter selbstverständlich mit der Zeit zusätzliche Möglichkeiten geschaffen haben, um mit unserem API zu kommunizieren, so dass sich die Anzahl der Requests völlig automatisch erhöhen musste.

Ein erster Schritt zu faireren Limits

Um den Vorgang für Kunden und Integrationen transparenter zu machen, haben wir uns entschieden ein „API Fair Use Modell“ einzuführen. Schon seit längerem kommunizieren wir die harten Limits aus den oben genannten Gründen nicht mehr auf unseren Seiten. Das neue Fair Use Modell gibt nun aber allen Beteiligten die Möglichkeit, früher auf ein mögliches Erreichen des Request Limits zu reagieren.

Um dies zu erreichen, geben wir seit einiger Zeit bereits die folgenden vier zusätzlichen Header-Parameter in der Response unseres APIs zurück:

  • RateLimit-Interval
  • RateLimit-Remaining
  • RateLimit-Reset
  • RateLimit-Limit

Jedem Nutzer stehen nach dem neuen Modell eine bestimmte Anzahl an Requests innerhalb eines bestimmten Zeitraums zur Verfügung. Der Parameter RateLimit-Interval gibt zurück, wie groß das Intervall für den jeweiligen Nutzer ist. Wie viele Requests dieser innerhalb des aktuellen Intervalls noch machen kann, gibt der Parameter RateLimit-Remaining zurück. Und schlussendlich kann man ermitteln, wann das Limit wieder zurück gesetzt wird, indem man den Parameter RateLimit-Reset ausliest.

Dies ermöglicht es einer Integration zum Beispiel die Anzahl der Requests zu verringern, wenn man aller Voraussicht nach an ein Limit stoßen könnte. Oder hält Requests an unser API so lange in einer internen Queue, bis die Zeit zum Reset des Limits abgelaufen ist. Eine Möglichkeit, die insbesondere bei einer Stapelverarbeitung wertvoll sein kann, um frühzeitig zu erkennen, dass diese fehlschlagen könnte.