APIs sind eine gro\u00dfartige M\u00f6glichkeit f\u00fcr Softwareanwendungen, miteinander zu kommunizieren. Sie erm\u00f6glichen es Softwareanwendungen, miteinander zu interagieren und Ressourcen oder Privilegien zu teilen.<\/p>\n
Heute bieten viele B2B-Unternehmen ihre Dienste \u00fcber APIs an, die von Anwendungen in jeder Programmiersprache und jedem Framework genutzt werden k\u00f6nnen. Das macht sie jedoch anf\u00e4llig f\u00fcr DoS- und DDoS-Angriffe und kann auch zu einer ungleichen Verteilung der Bandbreite zwischen den Nutzern f\u00fchren. Um diese Probleme zu l\u00f6sen, wird eine Technik eingesetzt, die als API-Rate-Limiting bekannt ist. Die Idee ist einfach: Du begrenzst die Anzahl der Anfragen, die Nutzer\/innen an deine API stellen k\u00f6nnen.<\/p>\n
In diesem Leitfaden erf\u00e4hrst du, was eine API-Ratenbegrenzung ist, welche verschiedenen M\u00f6glichkeiten es gibt und welche Best Practices und Beispiele du bei der Einrichtung von API-Ratenbegrenzungen beachten solltest.
\n
Einfach ausgedr\u00fcckt, bedeutet API-Ratenbegrenzung, dass ein Schwellenwert oder eine Grenze f\u00fcr die Anzahl der Zugriffe auf eine API<\/a> durch die Nutzer\/innen festgelegt wird. Die Grenzen k\u00f6nnen auf verschiedene Arten festgelegt werden.<\/p>\n Eine M\u00f6glichkeit, eine Ratenbegrenzung festzulegen, besteht darin, die Anzahl der Zugriffe eines bestimmten Nutzers auf die API<\/a> innerhalb eines bestimmten Zeitraums zu reduzieren. Dies kann erreicht werden, indem die Anzahl der Anfragen mit demselben API-Schl\u00fcssel oder derselben IP-Adresse gez\u00e4hlt wird und bei Erreichen eines Schwellenwerts weitere Anfragen gedrosselt oder verweigert werden.<\/p>\n In vielen F\u00e4llen m\u00f6chten Entwickler die verf\u00fcgbare Bandbreite f\u00fcr ihre API gleichm\u00e4\u00dfig auf bestimmte geografische Standorte verteilen.<\/p>\n Der neue Vorab-Dienst ChatGPT<\/a> ist ein gutes Beispiel f\u00fcr eine ortsabh\u00e4ngige Ratenbegrenzung<\/a>, denn mit der Einf\u00fchrung der kostenpflichtigen Version wurden die Anfragen in der kostenlosen Version des Dienstes auf Basis der Nutzerstandorte begrenzt. Das war sinnvoll, da die kostenlose Vorabversion von Nutzern auf der ganzen Welt verwendet werden sollte, um eine gute Stichprobe von Nutzungsdaten f\u00fcr den Dienst zu erhalten.<\/p>\n Die serverbasierte Ratenbegrenzung ist eine interne Ratenbegrenzung, die auf dem Server implementiert wird, um eine gerechte Verteilung der Serverressourcen wie CPU, Speicher, Festplattenplatz usw. zu gew\u00e4hrleisten. Dazu wird auf jedem Server einer Bereitstellung ein Limit eingerichtet.<\/p>\n Wenn ein Server sein Limit erreicht, werden weitere eingehende Anfragen an einen anderen Server mit freien Kapazit\u00e4ten weitergeleitet. Wenn alle Server ihre Kapazit\u00e4t erreicht haben, erh\u00e4lt der Nutzer die Antwort 429 Too Many Requests<\/a>. Es ist wichtig zu wissen, dass serverbasierte Ratenbegrenzungen f\u00fcr alle Kunden gelten, unabh\u00e4ngig von ihrem geografischen Standort, der Uhrzeit des Zugriffs oder anderen Faktoren.<\/p>\n\n Abgesehen von der Art der Implementierung der Ratenbeschr\u00e4nkungen kannst du die Ratenbeschr\u00e4nkungen auch anhand ihrer Auswirkungen auf den Endnutzer klassifizieren. Einige g\u00e4ngige Arten sind:<\/p>\n Es gibt viele Gr\u00fcnde, warum du eine Ratenbegrenzung in deinen Web-APIs<\/a> einf\u00fchren solltest. Einige der wichtigsten Gr\u00fcnde sind:<\/p>\n Der erste Grund, warum du eine API-Ratenbegrenzung in deiner Anwendung einf\u00fchren solltest, ist der Schutz deiner Ressourcen vor der Ausbeutung durch Nutzer\/innen mit b\u00f6swilligen Absichten. Angreifer k\u00f6nnen Techniken wie DDoS-Angriffe<\/a> nutzen, um den Zugang zu deinen Ressourcen zu blockieren und zu verhindern, dass deine Anwendung f\u00fcr andere Nutzer normal funktioniert. Mit einem Ratenlimit stellst du sicher, dass du es Angreifern nicht leicht machst, deine APIs zu beeintr\u00e4chtigen.<\/p>\n Neben dem Schutz deiner Ressourcen erm\u00f6glicht dir die Ratenbegrenzung auch, deine API-Ressourcen unter den Nutzern aufzuteilen. Das bedeutet, dass du abgestufte Preismodelle erstellen und auf die dynamischen Bed\u00fcrfnisse deiner Kunden eingehen kannst, ohne dass sich diese auf andere Kunden auswirken.<\/p>\n Ratenbegrenzung ist auch gleichbedeutend mit Kostenbegrenzung. Das bedeutet, dass du deine Ressourcen vern\u00fcnftig auf deine Nutzer\/innen verteilen kannst. Mit einer partitionierten Struktur ist es einfacher, die Kosten f\u00fcr den Unterhalt des Systems abzusch\u00e4tzen. Auftretende Spitzen k\u00f6nnen intelligent gehandhabt werden, indem du die richtige Menge an Ressourcen bereitstellst oder stilllegst.<\/p>\n Viele APIs basieren auf einer verteilten Architektur, die mehrere Worker\/Threads\/Instanzen zur Bearbeitung eingehender Anfragen einsetzt. In einer solchen Struktur kannst du mithilfe von Ratenbeschr\u00e4nkungen die Arbeitslast kontrollieren, die an jeden Worker-Knoten \u00fcbergeben wird. So kannst du sicherstellen, dass die Worker Nodes eine gerechte und nachhaltige Arbeitslast erhalten. Du kannst bei Bedarf einfach Worker hinzuf\u00fcgen oder entfernen, ohne das gesamte API-Gateway umzustrukturieren.<\/p>\n Eine weitere g\u00e4ngige Methode zur Kontrolle der API-Nutzung ist die Festlegung eines Burst-Limits (auch bekannt als Drosselung) anstelle eines Ratenlimits. Burst Limits sind Ratenbegrenzungen, die f\u00fcr ein sehr kleines Zeitintervall, z. B. ein paar Sekunden, eingef\u00fchrt werden. Anstatt ein Limit von 1,3 Millionen Anfragen pro Monat festzulegen, k\u00f6nntest du zum Beispiel ein Limit von 5 Anfragen pro Sekunde festlegen. Das entspricht zwar dem gleichen monatlichen Datenverkehr, stellt aber sicher, dass deine Kunden deine Server nicht \u00fcberlasten, indem sie Tausende von Anfragen auf einmal senden.<\/p>\n Bei Burst-Limits werden die Anfragen oft bis zum n\u00e4chsten Intervall verz\u00f6gert, anstatt sie abzulehnen. Es wird auch oft empfohlen, sowohl Raten- als auch Burst-Limits zu verwenden, um den Datenverkehr und die Nutzung optimal zu kontrollieren.<\/p>\n F\u00fcr die Implementierung gibt es einige Methoden, mit denen du eine API-Ratenbegrenzung in deiner Anwendung einrichten kannst. Dazu geh\u00f6ren:<\/p>\n Eine der einfachsten Methoden zur Beschr\u00e4nkung des API-Zugriffs sind Warteschlangen f\u00fcr Anfragen. Anfragewarteschlangen sind ein Mechanismus, bei dem eingehende Anfragen in Form einer Warteschlange gespeichert und nacheinander bis zu einer bestimmten Grenze abgearbeitet werden.<\/p>\n Ein g\u00e4ngiger Anwendungsfall f\u00fcr Warteschlangen ist die Trennung der eingehenden Anfragen von kostenlosen und bezahlten Nutzern. Hier erf\u00e4hrst du, wie du das in einer Express-App<\/a> mit dem Paket Die Drosselung ist eine weitere Technik, um den Zugriff auf APIs zu kontrollieren. Anstatt den Zugang nach Erreichen eines Schwellenwerts zu sperren, konzentriert sich die Drosselung darauf, die Spitzen im API-Verkehr auszugleichen, indem kleine Schwellenwerte f\u00fcr kleine Zeitspannen festgelegt werden. Anstatt ein Ratenlimit von z. B. 3 Millionen Aufrufen pro Monat festzulegen, werden bei der Drosselung Grenzen von 10 Aufrufen pro Sekunde gesetzt. Sobald ein Kunde mehr als 10 Aufrufe in einer Sekunde sendet, werden die n\u00e4chsten Anfragen in derselben Sekunde automatisch gedrosselt, aber der Kunde erh\u00e4lt in der n\u00e4chsten Sekunde sofort wieder Zugang zur API.<\/p>\n Du kannst die Drosselung in Express mit dem Paket Du kannst die Anwendung mit einem Lasttest-Tool wie AutoCannon<\/a> testen. Du kannst AutoCannon installieren, indem du den folgenden Befehl in deinem Terminal ausf\u00fchrst:<\/p>\n Du kannst die App mit folgendem Befehl testen:<\/p>\n Der Test verwendet 10 gleichzeitige Verbindungen, die Anfragen an die API senden. Hier ist das Ergebnis des Tests:<\/p>\n Da nur 10 Anfragen pro Sekunde erlaubt waren (mit einem zus\u00e4tzlichen Burst von 5 Anfragen), wurden nur 114 Anfragen erfolgreich von der API bearbeitet, und die restlichen Anfragen wurden mit einem 503-Fehlercode beantwortet, mit der Bitte, einige Zeit zu warten.<\/p>\n Obwohl die Ratenbegrenzung wie ein einfaches Konzept aussieht, das mit einer Warteschlange umgesetzt werden kann, kann sie in Wirklichkeit auf verschiedene Weise implementiert werden und bietet verschiedene Vorteile. Hier sind einige g\u00e4ngige Algorithmen, die zur Implementierung der Ratenbegrenzung verwendet werden:<\/p>\n Der Fixed-Window-Algorithmus ist einer der einfachsten Algorithmen zur Ratenbegrenzung. Er begrenzt die Anzahl der Anfragen, die in einem bestimmten Zeitintervall bearbeitet werden k\u00f6nnen.<\/p>\n Du legst eine feste Anzahl von Anfragen fest, zum Beispiel 100, die der API-Server in einer Stunde bearbeiten kann. Wenn nun die 101. Anfrage eintrifft, verweigert der Algorithmus ihre Bearbeitung. Wenn das Zeitintervall zur\u00fcckgesetzt wird (d.h. in der n\u00e4chsten Stunde), k\u00f6nnen weitere 100 eingehende Anfragen bearbeitet werden.<\/p>\n Dieser Algorithmus ist einfach zu implementieren und funktioniert in vielen F\u00e4llen gut, in denen eine serverseitige Ratenbegrenzung erforderlich ist, um die Bandbreite zu kontrollieren (im Gegensatz zur Verteilung der Bandbreite auf die Nutzer\/innen). Er kann jedoch zu einem starken Datenverkehr\/einer starken Verarbeitung an den R\u00e4ndern des festen Zeitintervalls f\u00fchren. Der Sliding-Window-Algorithmus ist eine bessere Alternative, wenn du eine gleichm\u00e4\u00dfige Verarbeitung brauchst.<\/p>\n Der Sliding-Window-Algorithmus ist eine Variante des Fixed-Window-Algorithmus. Anstatt feste, vordefinierte Zeitintervalle zu verwenden, nutzt dieser Algorithmus ein rollierendes Zeitfenster, um die Anzahl der bearbeiteten und eingehenden Anfragen zu verfolgen.<\/p>\n Anstatt die absoluten Zeitintervalle (von z. B. jeweils 60 Sekunden) zu betrachten, wie z. B. 0s bis 60s, 61s bis 120s usw., betrachtet der Sliding-Window-Algorithmus die letzten 60 Sekunden ab Eingang einer Anfrage. Angenommen, eine Anfrage geht in der 82. Sekunde ein; dann z\u00e4hlt der Algorithmus die Anzahl der Anfragen, die zwischen 22s und 82s bearbeitet wurden (anstelle des absoluten Intervalls 60s bis 120s), um festzustellen, ob diese Anfrage bearbeitet werden kann oder nicht. So kann verhindert werden, dass eine gro\u00dfe Anzahl von Anfragen sowohl in der 59. als auch in der 61. Sekunde bearbeitet wird und den Server f\u00fcr einen sehr kurzen Zeitraum \u00fcberlastet.<\/p>\n Dieser Algorithmus kann Burst-Verkehr besser bew\u00e4ltigen, ist aber im Vergleich zum Fixed-Window-Algorithmus schwieriger zu implementieren und zu warten.<\/p>\n Bei diesem Algorithmus wird ein fiktiver Eimer mit Token gef\u00fcllt, und jedes Mal, wenn der Server eine Anfrage bearbeitet, wird ein Token aus dem Eimer genommen. Wenn der Eimer leer ist, kann der Server keine Anfragen mehr bearbeiten. Weitere Anfragen werden entweder aufgeschoben oder abgelehnt, bis der Eimer wieder gef\u00fcllt ist.<\/p>\n Der Token-Bucket wird mit einer festen Rate aufgef\u00fcllt (bekannt als Token-Generierungsrate), und die maximale Anzahl der Token, die im Bucket gespeichert werden k\u00f6nnen, ist ebenfalls festgelegt (bekannt als Bucket-Tiefe).<\/p>\n Indem du die Token-Regenerierungsrate und die Tiefe des Buckets kontrollierst, kannst du den maximalen Verkehrsfluss steuern, den die API zul\u00e4sst. Das Paket Der gr\u00f6\u00dfte Vorteil dieses Algorithmus ist, dass er Burst-Verkehr unterst\u00fctzt, solange er in der Bucket-Tiefe untergebracht werden kann. Das ist besonders n\u00fctzlich f\u00fcr unvorhersehbaren Datenverkehr.<\/p>\n Der Leaky-Bucket-Algorithmus ist ein weiterer Algorithmus f\u00fcr den Umgang mit API-Verkehr. Anstatt eine Bucket-Tiefe einzuhalten, die festlegt, wie viele Anfragen in einem bestimmten Zeitraum bearbeitet werden k\u00f6nnen (wie bei einem Token Bucket), erlaubt er einen festen Fluss von Anfragen aus dem Bucket, was dem stetigen Fluss von Wasser aus einem undichten Eimer entspricht.<\/p>\n Die Eimertiefe wird in diesem Fall verwendet, um zu bestimmen, wie viele Anfragen in die Warteschlange aufgenommen werden k\u00f6nnen, bevor der Eimer \u00fcberl\u00e4uft, d.h. eingehende Anfragen abgewiesen werden.<\/p>\n Der Leaky Bucket verspricht einen stetigen Fluss von Anfragen und ist im Gegensatz zum Token Bucket nicht in der Lage, Spitzen im Datenverkehr zu bew\u00e4ltigen.<\/p>\n Jetzt wei\u00dft du, was API-Ratenbegrenzung ist und wie es umgesetzt wird. Hier sind einige Best Practices, die du bei der Implementierung in deiner Anwendung beachten solltest.<\/p>\n Wenn du eine API-Ratenbeschr\u00e4nkung in Erw\u00e4gung ziehst, solltest du immer versuchen, eine angemessene kostenlose Stufe anzubieten, mit der deine potenziellen Nutzer deine API ausprobieren k\u00f6nnen. Es muss nicht sehr gro\u00dfz\u00fcgig sein, aber es sollte ausreichen, damit sie deine API bequem in ihrer Entwicklungs-Anwendung testen k\u00f6nnen.<\/p>\n Auch wenn API-Ratenbeschr\u00e4nkungen wichtig sind, um die Qualit\u00e4t deiner API-Endpunkte f\u00fcr deine Nutzer\/innen aufrechtzuerhalten, kann ein kleines, ungedrosseltes Gratis-Tier dir helfen, neue Nutzer\/innen zu gewinnen.<\/p>\n Wenn eine Nutzerin oder ein Nutzer das von dir festgelegte API-Ratenlimit \u00fcberschreitet, gibt es einige Dinge, die du beachten solltest, um sicherzustellen, dass du ein positives Nutzererlebnis bieten und gleichzeitig deine Ressourcen sch\u00fctzen kannst. Einige Fragen, die du stellen solltest, und \u00dcberlegungen, die du anstellen musst, sind:<\/p>\n Als Erstes musst du deine Nutzer\/innen dar\u00fcber informieren, dass sie die festgelegte API-Ratengrenze \u00fcberschritten haben. Dazu musst du die API-Antwort in eine voreingestellte Meldung \u00e4ndern, die das Problem erkl\u00e4rt. Es ist wichtig, dass der Statuscode f\u00fcr diese Antwort 429 „Too Many Requests“ lautet<\/i> Es ist auch \u00fcblich, das Problem im Antworttext zu erkl\u00e4ren. Hier ist ein Beispiel f\u00fcr einen Antworttext, der so aussehen k\u00f6nnte:<\/p>\n Der oben gezeigte Beispiel-Antworttext nennt den Fehlernamen und die Fehlerbeschreibung und gibt au\u00dferdem eine Zeitspanne an (normalerweise in Sekunden), nach der der Nutzer erneut versuchen kann, Anfragen zu senden. Ein beschreibender Antworttext wie dieser hilft den Nutzern zu verstehen, was schief gelaufen ist und warum sie nicht die erwartete Antwort erhalten haben. Au\u00dferdem erfahren sie, wie lange sie warten m\u00fcssen, bevor sie eine weitere Anfrage senden k\u00f6nnen.<\/p>\n Ein weiterer Entscheidungspunkt ist, was zu tun ist, wenn ein Nutzer die festgelegte API-Rate \u00fcberschreitet. Normalerweise w\u00fcrdest du den Nutzer daran hindern, mit dem Server zu interagieren, indem du eine Antwort 429 „Too many requests“ zur\u00fcckschickst, wie du oben gesehen hast. Du solltest aber auch einen anderen Ansatz in Betracht ziehen – die Drosselung.<\/p>\n Anstatt den Zugriff auf die Serverressource komplett zu unterbinden, kannst du stattdessen die Gesamtzahl der Anfragen, die der Nutzer innerhalb eines bestimmten Zeitraums senden kann, verlangsamen. Das ist n\u00fctzlich, wenn du deinen Nutzern einen kleinen Klaps auf die Hand geben willst, sie aber trotzdem weiterarbeiten lassen willst, wenn sie ihr Anfragevolumen reduzieren.<\/p>\n API-Ratenbeschr\u00e4nkungen sind unangenehm – sie hindern deine Nutzer daran, mit deinen API-Diensten zu interagieren und sie zu nutzen. Besonders schlimm ist es f\u00fcr Nutzer\/innen, die immer wieder \u00e4hnliche Anfragen stellen m\u00fcssen, z. B. den Zugriff auf einen Wettervorhersagedatensatz, der nur w\u00f6chentlich aktualisiert wird, oder das Abrufen einer Liste von Optionen f\u00fcr ein Dropdown-Men\u00fc, das vielleicht nur alle paar Tage ge\u00e4ndert wird. In diesen F\u00e4llen w\u00e4re ein intelligenter Ansatz die Implementierung von Caching.<\/p>\n Caching<\/a> ist eine Hochgeschwindigkeits-Speicherabstraktion, die in F\u00e4llen eingesetzt wird, in denen das Datenzugriffsvolumen hoch ist, die Daten sich aber nicht sehr oft \u00e4ndern. Anstatt einen API-Aufruf zu t\u00e4tigen, der m\u00f6glicherweise mehrere interne Dienste aufruft und hohe Kosten verursacht, k\u00f6nntest du die am h\u00e4ufigsten genutzten Endpunkte zwischenspeichern, so dass die zweite Anfrage aus dem statischen Cache bedient wird, was in der Regel schneller und kosteng\u00fcnstiger ist und die Arbeitslast deiner Hauptdienste verringern kann.<\/p>\n Ein anderer Fall kann sein, dass du eine ungew\u00f6hnlich hohe Anzahl von Anfragen von einem Nutzer erh\u00e4ltst. Selbst wenn du ein Ratenlimit gesetzt hast, st\u00f6\u00dft er immer wieder an seine Kapazit\u00e4tsgrenzen und bekommt eine Ratenbegrenzung. Solche Situationen deuten darauf hin, dass die M\u00f6glichkeit eines API-Missbrauchs besteht.<\/p>\n Um deine Dienste vor \u00dcberlastung zu sch\u00fctzen und ein einheitliches Erlebnis f\u00fcr den Rest deiner Nutzer zu gew\u00e4hrleisten, solltest du in Erw\u00e4gung ziehen, den verd\u00e4chtigen Nutzer komplett von der API auszuschlie\u00dfen. Dies wird als Circuit Breaking bezeichnet und klingt zwar \u00e4hnlich wie eine Ratenbegrenzung, wird aber in der Regel dann eingesetzt, wenn das System mit einer \u00dcberlast an Anfragen konfrontiert ist und Zeit braucht, um sich zu verlangsamen, damit es seine Dienstqualit\u00e4t wiederherstellen kann.<\/p>\n API-Ratenbegrenzungen sollen deine Ressourcen gleichm\u00e4\u00dfig auf deine Nutzer\/innen verteilen, k\u00f6nnen aber manchmal unn\u00f6tige Probleme f\u00fcr deine Nutzer\/innen verursachen oder sogar auf verd\u00e4chtige Aktivit\u00e4ten hinweisen.<\/p>\n Wenn du eine robuste \u00dcberwachungsl\u00f6sung<\/a> f\u00fcr deine API einrichtest, kannst du herausfinden, wie oft die Ratenlimits von deinen Nutzern erreicht werden, ob du die allgemeinen Limits \u00fcberdenken musst, wobei du die durchschnittliche Arbeitsbelastung deiner Nutzer im Auge behalten solltest, und Nutzer identifizieren, die ihre Limits h\u00e4ufig \u00fcberschreiten (was darauf hindeuten k\u00f6nnte, dass sie m\u00f6glicherweise bald eine Erh\u00f6hung ihrer Limits ben\u00f6tigen oder auf verd\u00e4chtige Aktivit\u00e4ten \u00fcberwacht werden m\u00fcssen). In jedem Fall hilft dir ein aktives Monitoring, die Auswirkungen deiner API-Ratenbegrenzungen besser zu verstehen.<\/p>\n Eine Ratenbegrenzung kann auf mehreren Ebenen implementiert werden (Benutzer, Anwendung oder System). Viele Menschen machen den Fehler, Ratenbegrenzungen nur auf einer dieser Ebenen einzurichten und zu erwarten, dass damit alle m\u00f6glichen F\u00e4lle abgedeckt sind. Das ist zwar nicht unbedingt ein Anti-Pattern, kann sich aber in manchen F\u00e4llen als ineffektiv erweisen.<\/p>\n Wenn die eingehenden Anfragen die Netzwerkschnittstelle deines Systems \u00fcberlasten, kann es sein, dass die Ratenbegrenzung auf Anwendungsebene nicht einmal in der Lage ist, die Arbeitslast zu optimieren. Deshalb ist es am besten, wenn du die Regeln zur Ratenbegrenzung auf mehreren Ebenen einrichtest, vorzugsweise auf den obersten Schichten deiner Architektur, um sicherzustellen, dass keine Engp\u00e4sse entstehen.<\/p>\n In diesem Abschnitt erf\u00e4hrst du, wie du die API-Ratenbeschr\u00e4nkungen f\u00fcr einen bestimmten API-Endpunkt testest und wie du eine Nutzungskontrolle auf deinem Client implementierst, um sicherzustellen, dass du deine API-Ratenbeschr\u00e4nkungen nicht aussch\u00f6pfst.<\/p>\n Um die Ratenbeschr\u00e4nkung f\u00fcr eine API zu ermitteln, solltest du immer zuerst die API-Dokumente lesen, um herauszufinden, ob die Beschr\u00e4nkungen klar definiert sind. In den meisten F\u00e4llen findest du in den API-Dokumenten das Limit und wie es implementiert wurde. Du solltest das API-Ratenlimit nur dann „testen“, wenn du es nicht aus den API-Dokumenten, dem Support oder der Community herausfinden kannst. Denn wenn du eine API testest, um ihr Tariflimit herauszufinden, wirst du dein Tariflimit mindestens einmal aussch\u00f6pfen, was finanzielle Kosten und\/oder die Nichtverf\u00fcgbarkeit der API f\u00fcr eine bestimmte Zeit zur Folge haben kann.<\/p>\n Wenn du das Ratenlimit manuell ermitteln willst, solltest du zun\u00e4chst mit einem einfachen API-Testtool wie Postman beginnen, um manuell Anfragen an die API zu stellen und zu sehen, ob du ihr Ratenlimit aussch\u00f6pfen kannst. Wenn das nicht der Fall ist, kannst du ein Lasttest-Tool wie Autocannon oder Gatling verwenden, um eine gro\u00dfe Anzahl von Anfragen zu simulieren und zu sehen, wie viele Anfragen von der API bearbeitet werden k\u00f6nnen, bevor sie mit einem 429-Statuscode antwortet.<\/p>\n Ein anderer Ansatz ist die Verwendung eines Tools zur \u00dcberpr\u00fcfung der Ratenbegrenzung wie das von AppBrokers Wenn du dir jedoch nicht sicher bist, wie hoch die Ratenbegrenzung einer API ist, kannst du immer versuchen, deine Anforderungen an die Anfragen zu sch\u00e4tzen und auf deiner Client-Seite Limits einzurichten, um sicherzustellen, dass die Anzahl der Anfragen deiner Anwendung diese Zahl nicht \u00fcberschreitet. Wie du das machst, erf\u00e4hrst du im n\u00e4chsten Abschnitt.<\/p>\n Wenn du von deinem Code aus eine API aufrufst, solltest du auf deiner Seite Drosselungen einrichten, um sicherzustellen, dass du nicht versehentlich zu viele API-Aufrufe machst und dein API-Limit aussch\u00f6pfst. Es gibt mehrere M\u00f6glichkeiten, dies zu tun. Eine beliebte Methode ist die Drosselmethode in der Lodash-Dienstprogramm-Bibliothek.<\/p>\n Bevor du einen API-Aufruf drosseln kannst, musst du eine API erstellen. Hier ist ein Beispielcode f\u00fcr eine Node.js-basierte API, die die durchschnittliche Anzahl der Anfragen pro Minute auf der Konsole ausgibt:<\/p>\n Sobald diese Anwendung l\u00e4uft, wird sie die durchschnittliche Anzahl der Anfragen pro Sekunde ausgeben:<\/p>\n Als N\u00e4chstes erstellst du eine neue JavaScript-Datei mit dem Namen test-throttle.js<\/b> und speicherst den folgenden Code darin:<\/p>\n Sobald du dieses Skript ausf\u00fchrst, wirst du feststellen, dass die durchschnittliche Anzahl der Anfragen f\u00fcr den Server auf fast 10 ansteigt:<\/p>\n Was w\u00e4re, wenn diese API zum Beispiel nur 6 Anfragen pro Sekunde zulie\u00dfe? Du w\u00fcrdest die durchschnittliche Anzahl der Anfragen unter diesem Wert halten wollen. Wenn dein Client jedoch eine Anfrage aufgrund einer Benutzeraktivit\u00e4t sendet, wie z. B. das Klicken auf eine Schaltfl\u00e4che oder ein Scrollen, kannst du die Anzahl der API-Aufrufe m\u00f6glicherweise nicht begrenzen.<\/p>\n Die Funktion Als N\u00e4chstes aktualisierst du die Datei test-throttle.js<\/b> und f\u00fcgst den folgenden Code ein:<\/p>\n Wenn du dir jetzt die Serverprotokolle ansiehst, wirst du eine \u00e4hnliche Ausgabe sehen:<\/p>\n Obwohl deine Anwendung die Funktion Wenn du mit ratenbegrenzten APIs arbeitest, kann es vorkommen, dass du verschiedene Antworten erh\u00e4ltst, die anzeigen, dass ein Ratenlimit \u00fcberschritten wurde. In den meisten F\u00e4llen erh\u00e4ltst du den Statuscode 429 mit einer Meldung, die einer der folgenden \u00e4hnelt:<\/p>\n Die Meldung, die du erh\u00e4ltst, h\u00e4ngt jedoch von der Implementierung der API ab, die du verwendest. Diese Implementierung kann variieren, und einige APIs verwenden den Statuscode 429 m\u00f6glicherweise gar nicht. Hier sind einige andere Arten von Fehlercodes und Meldungen, die du bei der Arbeit mit APIs mit Ratenbegrenzung erhalten kannst:<\/p>\n Bei der Festlegung der Ratenbegrenzung f\u00fcr deine API kann es hilfreich sein, einen Blick darauf zu werfen, wie einige der Top-API-Anbieter dies tun:<\/p>\n Bei der Entwicklung von APIs ist es wichtig, den Datenverkehr optimal zu steuern. Wenn du deine Datenverkehrssteuerung nicht genau im Auge beh\u00e4ltst, wirst du bald mit einer \u00fcberlasteten und nicht funktionierenden API dastehen. Umgekehrt ist es bei der Arbeit mit einer ratenbegrenzten API wichtig zu verstehen, wie die Ratenbegrenzung funktioniert und wie du die API nutzen solltest, um maximale Verf\u00fcgbarkeit und Nutzung zu gew\u00e4hrleisten.<\/p>\n In diesem Leitfaden erf\u00e4hrst du mehr \u00fcber die API-Ratenbegrenzung, warum sie notwendig ist, wie sie implementiert werden kann und welche Best Practices du bei der Arbeit mit API-Ratenbegrenzungen beachten solltest.<\/p>\n Probiere das Anwendungs-Hosting<\/a> von Kinsta aus und starte dein n\u00e4chstes Node.js<\/a>-Projekt noch heute!<\/p>\n Arbeitest du mit einer ratenbegrenzten API? Oder hast du eine Ratenbegrenzung in deiner eigenen API implementiert? Lass es uns in den Kommentaren unten wissen!<\/i><\/p>\n","protected":false},"excerpt":{"rendered":" APIs sind eine gro\u00dfartige M\u00f6glichkeit f\u00fcr Softwareanwendungen, miteinander zu kommunizieren. Sie erm\u00f6glichen es Softwareanwendungen, miteinander zu interagieren und Ressourcen oder Privilegien zu teilen. Heute bieten viele …<\/p>\n","protected":false},"author":199,"featured_media":63192,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[925],"class_list":["post-63191","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-api"],"yoast_head":"\n1. Nutzerbasierte Limits<\/h3>\n
2. Standortbezogene Beschr\u00e4nkungen<\/h3>\n
3. Serverbasierte Begrenzungen<\/h3>\n
Arten von API-Ratenbegrenzungen<\/h2>\n
\n
Warum ist eine Ratenbegrenzung notwendig?<\/h2>\n
1. Schutz des Ressourcenzugangs<\/h3>\n
2. Aufteilung des Kontingents unter den Nutzern<\/h3>\n
3. Steigerung der Kosteneffizienz<\/h3>\n
4. Fluss zwischen Workern verwalten<\/h3>\n
Burst-Grenzen verstehen<\/h2>\n
3 Methoden zur Implementierung von Ratenbegrenzungen<\/h2>\n
1. Anfragewarteschlangen<\/h3>\n
express-queue<\/code> machen kannst:<\/p>\nconst express = require('express')\nconst expressQueue = require('express-queue');\n\nconst app = express()\n\nconst freeRequestsQueue = expressQueue({\n activeLimit: 1, \/\/ Maximum requests to process at once\n queuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\nconst paidRequestsQueue = expressQueue({\n activeLimit: 5, \/\/ Maximum requests to process at once\n queuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\n\/\/ Middleware that selects the appropriate queue handler based on the presence of an API token in the request\nfunction queueHandlerMiddleware(req, res, next) {\n \/\/ Check if the request contains an API token\n const apiToken = req.headers['api-token'];\n\n if (apiToken && isValidToken(apiToken)) {\n console.log(\"Paid request received\")\n paidRequestsQueue(req, res, next);\n } else {\n console.log(\"Free request received\")\n freeRequestsQueue(req, res, next);\n }\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', queueHandlerMiddleware, (req, res) => {\n res.status(200).json({ message: \"Processed!\" })\n});\n\n\/\/ Check here is the API token is valid or not\nconst isValidToken = () => {\n return true;\n}\n\napp.listen(3000);<\/code><\/pre>\n2. Drosselung<\/h3>\n
express-throttle<\/code> implementieren. Hier ist ein Beispiel f\u00fcr eine Express-Anwendung, die zeigt, wie du die Drosselung in deiner Anwendung einrichten kannst:<\/p>\nconst express = require('express')\nconst throttle = require('express-throttle')\n\nconst app = express()\n\nconst throttleOptions = {\n \"rate\": \"10\/s\",\n \"burst\": 5,\n \"on_allowed\": function (req, res, next, bucket) {\n res.set(\"X-Rate-Limit-Limit\", 10);\n res.set(\"X-Rate-Limit-Remaining\", bucket.tokens);\n next()\n },\n \"on_throttled\": function (req, res, next, bucket) {\n \/\/ Notify client\n res.set(\"X-Rate-Limit-Limit\", 10);\n res.set(\"X-Rate-Limit-Remaining\", 0);\n res.status(503).send(\"System overloaded, try again after a few seconds.\");\n }\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', throttle(throttleOptions), (req, res) => {\n res.status(200).json({ message: \"Processed!\" })\n});\n\napp.listen(3000);<\/code><\/pre>\nnpm install autocannon -g<\/code><\/pre>\nautocannon http:\/\/localhost:3000\/route<\/code><\/pre>\nRunning 10s test @ http:\/\/localhost:3000\/route\n\n10 connections\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \u2502 2.5% \u2502 50% \u2502 97.5% \u2502 99% \u2502 Avg \u2502 Stdev \u2502 Max \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Latency \u2502 0 ms \u2502 0 ms \u2502 1 ms \u2502 1 ms \u2502 0.04 ms \u2502 0.24 ms \u2502 17 ms \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \u2502 1% \u2502 2.5% \u2502 50% \u2502 97.5% \u2502 Avg \u2502 Stdev \u2502 Min \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Req\/Sec \u2502 16591 \u2502 16591 \u2502 19695 \u2502 19903 \u2502 19144 \u2502 1044.15 \u2502 16587 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Bytes\/Sec \u2502 5.73 MB \u2502 5.73 MB \u2502 6.8 MB \u2502 6.86 MB \u2502 6.6 MB \u2502 360 kB \u2502 5.72 MB \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nReq\/Bytes counts sampled once per second.\n# of samples: 11\n114 2xx responses, 210455 non 2xx responses\n211k requests in 11.01s, 72.6 MB read<\/code><\/pre>\n3. Algorithmen zur Ratenbegrenzung<\/h3>\n
Fixed-Window-Algorithmus<\/h4>\n
Sliding-Window-Algorithmus<\/h4>\n
Token Bucket Algorithmus<\/h4>\n
express-throttle<\/code>, das du vorhin gesehen hast, verwendet den Token Bucket Algorithmus, um den Datenverkehr der API zu drosseln oder zu kontrollieren.<\/p>\nLeaky-Bucket-Algorithmus<\/h4>\n
Best Practices f\u00fcr die API-Ratenbegrenzung<\/h2>\n
Biete eine kostenlose Stufe an, damit die Nutzer deine Dienste ausprobieren k\u00f6nnen<\/h3>\n
Entscheide, was passiert, wenn das Ratenlimit \u00fcberschritten wird<\/h3>\n
Welchen Fehlercode und welche Meldung werden deine Nutzer sehen?<\/h4>\n
{\n \"error\": \"Too Many Requests\",\n \"message\": \"You have exceeded the set API rate limit of X requests per minute. Please try again in a few minutes.\",\n \"retry_after\": 60\n}<\/code><\/pre>\nWerden neue Anfragen gedrosselt oder ganz gestoppt?<\/h4>\n
Caching und Kreislaufunterbrechung in Betracht ziehen<\/h3>\n
\u00dcberwache dein Setup genau<\/h3>\n
Ratenbegrenzung auf mehreren Ebenen implementieren<\/h3>\n
Arbeiten mit API-Ratenbeschr\u00e4nkungen<\/h2>\n
So testest du API-Ratenbeschr\u00e4nkungen<\/h3>\n
rate-limit-test-tool<\/a><\/code>. Dedizierte Tools wie dieses automatisieren den Prozess f\u00fcr dich und bieten dir au\u00dferdem eine Benutzeroberfl\u00e4che, um die Testergebnisse sorgf\u00e4ltig zu analysieren.<\/p>\nWie man API-Aufrufe drosselt<\/h3>\n
const express = require('express');\nconst app = express();\n\n\/\/ maintain a count of total requests\nlet requestTotalCount = 0;\nlet startTime = Date.now();\n\n\/\/ increase the count whenever any request is received\napp.use((req, res, next) => {\n requestTotalCount++;\n next();\n});\n\n\/\/ After each second, print the average number of requests received per second since the server was started\nsetInterval(() => {\n const elapsedTime = (Date.now() - startTime) \/ 1000;\n const averageRequestsPerSecond = requestTotalCount \/ elapsedTime;\n console.log(`Average requests per second: ${averageRequestsPerSecond.toFixed(2)}`);\n}, 1000);\n\napp.get('\/', (req, res) => {\n res.send('Hello World!');\n});\n\napp.listen(3000, () => {\n console.log('Server listening on port 3000!');\n});<\/code><\/pre>\nAverage requests per second: 0\nAverage requests per second: 0\nAverage requests per second: 0<\/code><\/pre>\n\/\/ function that calls the API and prints the response\nconst request = () => {\n fetch('http:\/\/localhost:3000')\n .then(r => r.text())\n .then(r => console.log(r))\n}\n\n\/\/ Loop to call the request function once every 100 ms, i.e., 10 times per second\nsetInterval(request, 100)<\/code><\/pre>\nAverage requests per second: 9.87\nAverage requests per second: 9.87\nAverage requests per second: 9.88<\/code><\/pre>\nthrottle()<\/code> aus der lodash<\/code> kann hier helfen. Installiere zun\u00e4chst die Bibliothek, indem du den folgenden Befehl ausf\u00fchrst:<\/p>\nnpm install lodash<\/code><\/pre>\n\/\/ import the lodash library\nconst { throttle } = require('lodash');\n\n\/\/ function that calls the API and prints the response\nconst request = () => {\n fetch('http:\/\/localhost:3000')\n .then(r => r.text())\n .then(r => console.log(r))\n}\n\n\/\/ create a throttled function that can only be called once every 200 ms, i.e., only 5 times every second\nconst throttledRequest = throttle(request, 200)\n\n\/\/ loop this throttled function to be called once every 100 ms, i.e., 10 times every second\nsetInterval(throttledRequest, 100)<\/code><\/pre>\nAverage requests per second: 4.74\nAverage requests per second: 4.80\nAverage requests per second: 4.83\n<\/code><\/pre>\nrequest<\/code> 10 Mal pro Sekunde aufruft, sorgt die Drosselfunktion daf\u00fcr, dass sie nur 5 Mal pro Sekunde aufgerufen wird, so dass du unter dem Ratenlimit bleibst. So kannst du die clientseitige Drosselung einrichten, um zu verhindern, dass die API-Ratenlimits ausgesch\u00f6pft werden.<\/p>\nH\u00e4ufige Fehler bei API-Ratenbeschr\u00e4nkungen<\/h2>\n
\n
\n
Wie Top-API-Anbieter API-Ratenlimits implementieren<\/h2>\n
\n
retry_after<\/code> Wert, mit dem du warten kannst, bevor du eine weitere Anfrage sendest.<\/li>\nx-rate-limit-reset<\/code> Header-Wert, der dir mitteilt, wann du den Zugriff wieder aufnehmen kannst.<\/li>\nX-Ratelimit-Used<\/code>, X-Ratelimit-Remaining<\/code> und X-Ratelimit-Reset<\/code> zur\u00fcck, anhand derer du feststellen kannst, wann und wie lange das Limit \u00fcberschritten werden k\u00f6nnte<\/li>\nX-App-Usage<\/code> oder einen X-Ad-Account-Usage<\/code> Header, damit du wei\u00dft, wann deine Nutzung gedrosselt wird.<\/li>\n<\/ul>\n\nZusammenfassung<\/h2>\n