TL;DR
Implementieren Sie API-Ratenbegrenzung mithilfe von Token-Bucket- oder Sliding-Window-Algorithmen. Geben Sie die Standard-IETF-Ratenbegrenzung-Header (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset) und 429 Too Many Requests zurück, wenn die Limits überschritten werden. Modern PetstoreAPI implementiert Ratenbegrenzung mit nutzerbezogenen Quoten und klaren Fehlermeldungen.
Einleitung
Ein Client sendet 10.000 Anfragen an Ihre API in einer Minute. Ihre Datenbank stürzt ab. Ihre Überwachungswarnungen werden ausgelöst. Ihre anderen Kunden können nicht auf die API zugreifen. Sie werden angegriffen – oder haben es vielleicht nur mit einem fehlerhaften Client in einer Wiederholungsschleife zu tun.
Ratenbegrenzung verhindert dies. Sie begrenzt, wie viele Anfragen ein Client in einem Zeitfenster stellen kann. Wenn die Grenze überschritten wird, geben Sie 429 Too Many Requests zurück. Der Client zieht sich zurück, und Ihre API bleibt funktionsfähig.
Der alte Swagger Petstore implementiert überhaupt keine Ratenbegrenzung. Modern PetstoreAPI implementiert Ratenbegrenzung mit Standard-IETF-Headern, nutzerbezogenen Quoten und klaren Fehlermeldungen.
In diesem Leitfaden lernen Sie Ratenbegrenzungsalgorithmen, Standard-Header und wie Modern PetstoreAPI die Ratenbegrenzung korrekt implementiert.
Warum APIs eine Ratenbegrenzung benötigen
Ratenbegrenzung schützt Ihre API vor Missbrauch und gewährleistet eine faire Nutzung.
Schutz vor Missbrauch
1. Denial-of-Service (DoS)-Angriffe
Ein Angreifer überflutet Ihre API mit Anfragen, um sie unerreichbar zu machen. Ratenbegrenzung begrenzt deren Auswirkungen.
2. Credential Stuffing
Angreifer versuchen Tausende von Benutzernamen-/Passwort-Kombinationen. Ratenbegrenzung verlangsamt sie.
3. Daten-Scraping
Bots scannen Ihren gesamten Datensatz. Ratenbegrenzung macht das Scraping unpraktisch.
4. Kostenkontrolle
Wenn Ihre API teure Dienste (KI-Modelle, Drittanbieter-APIs) aufruft, verhindert die Ratenbegrenzung ausufernde Kosten.
Faire Nutzung
1. Verhindern Sie, dass ein Client Ressourcen monopolisiert
Ohne Ratenbegrenzung kann ein Client, der 1000 Anfragen/Sekunde stellt, andere Clients aushungern.
2. Vorhersehbare Leistung
Ratenbegrenzung gewährleistet konsistente Antwortzeiten für alle Clients.
3. Gestufter Zugriff
Kostenlose Stufe: 100 Anfragen/Stunde. Bezahlte Stufe: 10.000 Anfragen/Stunde. Ratenbegrenzung erzwingt diese Stufen.
Betriebliche Vorteile
1. Kapazitätsplanung
Sie kennen die maximale Last, die Ihre API bewältigen wird.
2. Kostenprognose
Ratenbegrenzungen deckeln die Infrastrukturkosten.
3. Graduelle Leistungsreduzierung
Unter Last verhindert die Ratenbegrenzung Kaskadenfehler.
Ratenbegrenzungsalgorithmen
Verschiedene Algorithmen haben unterschiedliche Kompromisse.
1. Festes Fenster
Zählen Sie Anfragen in festen Zeitfenstern.
Funktionsweise:
Window 1 (00:00-00:59): 100 requests allowed
Window 2 (01:00-01:59): 100 requests allowed
Implementierung:
def is_allowed(user_id):
current_minute = get_current_minute()
key = f"rate_limit:{user_id}:{current_minute}"
count = redis.incr(key)
redis.expire(key, 60)
return count <= 100
Vorteile:
- Einfach zu implementieren
- Geringer Speicherverbrauch
Nachteile:
- Burst-Problem: Ein Client kann um 00:59 100 Anfragen und um 01:00 100 Anfragen stellen (200 in 2 Sekunden).
2. Gleitendes Fenster
Zählen Sie Anfragen in einem rollierenden Zeitfenster.
Funktionsweise:
Um 01:30 Uhr zählen Sie Anfragen von 00:30 bis 01:30 Uhr (letzte 60 Minuten).
Implementierung:
def is_allowed(user_id):
now = time.time()
window_start = now - 3600 # 1 hour ago
key = f"rate_limit:{user_id}"
# Remove old requests
redis.zremrangebyscore(key, 0, window_start)
# Count requests in window
count = redis.zcard(key)
if count < 100:
redis.zadd(key, {now: now})
redis.expire(key, 3600)
return True
return False
Vorteile:
- Kein Burst-Problem
- Genaue Ratenbegrenzung
Nachteile:
- Höherer Speicherverbrauch (speichert Zeitstempel für jede Anfrage)
- Komplexer
3. Token-Bucket
Tokens werden mit einer festen Rate zu einem Bucket hinzugefügt. Jede Anfrage verbraucht einen Token.
Funktionsweise:
Bucket capacity: 100 tokens
Refill rate: 10 tokens/second
Request: consumes 1 token
Implementierung:
def is_allowed(user_id):
now = time.time()
key = f"rate_limit:{user_id}"
# Get current state
data = redis.hgetall(key)
tokens = float(data.get('tokens', 100))
last_refill = float(data.get('last_refill', now))
# Refill tokens
elapsed = now - last_refill
tokens = min(100, tokens + elapsed * 10) # 10 tokens/sec
if tokens >= 1:
tokens -= 1
redis.hset(key, 'tokens', tokens)
redis.hset(key, 'last_refill', now)
redis.expire(key, 3600)
return True
return False
Vorteile:
- Erlaubt Bursts (bis zur Bucket-Kapazität)
- Gleichmäßige Ratenbegrenzung
- Industriestandard
Nachteile:
- Komplexer als ein festes Fenster
- Erfordert das Speichern des Zustands
4. Leaky-Bucket
Anfragen werden einer Warteschlange hinzugefügt und mit einer festen Rate verarbeitet.
Funktionsweise:
Queue capacity: 100 requests
Process rate: 10 requests/second
Vorteile:
- Gleichmäßige Ausgaberate
- Gut zum Schutz nachgelagerter Dienste
Nachteile:
- Fügt Latenz hinzu (Anfragen warten in der Warteschlange)
- Komplex zu implementieren
Welchen Algorithmus verwenden?
Für die meisten APIs: Token-Bucket
Es ist der Industriestandard, ermöglicht angemessene Bursts und bietet eine gleichmäßige Ratenbegrenzung.
Modern PetstoreAPI verwendet Token-Bucket mit nutzerbezogenen Quoten.
Standard-Ratenbegrenzungs-Header
Verwenden Sie IETF-Standard-Header (draft-ietf-httpapi-ratelimit-headers).
Standard-Header
RateLimit-Limit: Maximale Anzahl der Anfragen, die im Zeitfenster erlaubt sind
RateLimit-Limit: 100
RateLimit-Remaining: Verbleibende Anfragen im aktuellen Fenster
RateLimit-Remaining: 45
RateLimit-Reset: Sekunden bis zur Zurücksetzung der Ratenbegrenzung
RateLimit-Reset: 3600
Beispielantwort
GET /pets
200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 99
RateLimit-Reset: 3600
{
"data": [...]
}
Legacy-Header (veraltet)
Viele APIs verwenden Nicht-Standard-Header:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 99
X-RateLimit-Reset: 1710331200
Verwenden Sie diese nicht. Das X--Präfix ist veraltet, und das Format ist nicht standardisiert.
Wie Modern PetstoreAPI Ratenbegrenzung implementiert
Modern PetstoreAPI implementiert Token-Bucket-Ratenbegrenzung mit Standard-Headern.
Ratenbegrenzungen nach Stufen
Kostenlose Stufe:
- 100 Anfragen/Stunde
- 1.000 Anfragen/Tag
Pro-Stufe:
- 10.000 Anfragen/Stunde
- 100.000 Anfragen/Tag
Enterprise-Stufe:
- Benutzerdefinierte Limits
Implementierung
Erfolgreiche Anfrage:
GET /v1/pets
200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 99
RateLimit-Reset: 3540
{
"data": [...]
}
Ratenbegrenzung überschritten:
GET /v1/pets
429 Too Many Requests
Content-Type: application/problem+json
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 120
Retry-After: 120
{
"type": "https://petstoreapi.com/errors/rate-limit-exceeded",
"title": "Rate Limit Exceeded",
"status": 429,
"detail": "You have exceeded the rate limit of 100 requests per hour",
"instance": "/v1/pets",
"retryAfter": 120,
"limit": 100,
"window": "1h"
}
Pro-Benutzer vs. Pro-IP
Pro-Benutzer (authentifizierte Anfragen):
Ratenbegrenzung nach Benutzer-ID oder API-Schlüssel. Genauer und fairer.
user_id = get_authenticated_user()
is_allowed(user_id)
Pro-IP (nicht authentifizierte Anfragen):
Ratenbegrenzung nach IP-Adresse. Weniger genau (gemeinsame IPs, VPNs), aber besser als nichts.
ip_address = request.remote_addr
is_allowed(ip_address)
Modern PetstoreAPI verwendet pro-Benutzer-Ratenbegrenzung für authentifizierte Anfragen und pro-IP für öffentliche Endpunkte.
Antwortformat der Ratenbegrenzung
Wenn Ratenbegrenzungen überschritten werden, geben Sie 429 im RFC 9457 Fehlerformat zurück.
Antwortstruktur
{
"type": "https://petstoreapi.com/errors/rate-limit-exceeded",
"title": "Rate Limit Exceeded",
"status": 429,
"detail": "You have exceeded your rate limit. Please try again later.",
"instance": "/v1/pets",
"retryAfter": 120,
"limit": 100,
"remaining": 0,
"reset": 120,
"window": "1h"
}
Header
429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 120
Retry-After: 120
Retry-After: Informiert Clients, wann sie es erneut versuchen können (in Sekunden).
Ratenbegrenzungen mit Apidog testen
Apidog hilft Ihnen, das Verhalten der Ratenbegrenzung zu testen.
Testszenarien
1. Normaler Gebrauch:
Send 50 requests → All succeed
Check RateLimit-Remaining decreases
Senden Sie 50 Anfragen → Alle erfolgreich
Überprüfen Sie, ob RateLimit-Remaining abnimmt
2. Limit überschreiten:
Send 101 requests → 101st returns 429
Verify error response format
Check Retry-After header
Senden Sie 101 Anfragen → die 101. gibt 429 zurück
Fehlerantwortformat überprüfen
Retry-After-Header überprüfen
3. Reset-Verhalten:
Exceed limit → Wait for reset → Verify limit restored
Limit überschreiten → Auf Reset warten → Überprüfen, ob Limit wiederhergestellt ist
4. Verschiedene Stufen:
Test free tier (100/hour)
Test pro tier (10,000/hour)
Verify limits are enforced correctly
Kostenlose Stufe testen (100/Stunde)
Pro-Stufe testen (10.000/Stunde)
Überprüfen Sie, ob die Limits korrekt durchgesetzt werden
Apidog Testbeispiel
// Test rate limit headers
pm.test("Rate limit headers present", () => {
pm.response.to.have.header("RateLimit-Limit");
pm.response.to.have.header("RateLimit-Remaining");
pm.response.to.have.header("RateLimit-Reset");
});
// Test rate limit exceeded
pm.test("Returns 429 when limit exceeded", () => {
// Make 101 requests
for (let i = 0; i < 101; i++) {
pm.sendRequest("GET /v1/pets");
}
pm.response.to.have.status(429);
});
Best Practices für die Ratenbegrenzung
1. Standard-Header verwenden
Verwenden Sie IETF-Standard-Header, keine benutzerdefinierten X--Header.
2. 429 zurückgeben, nicht 403
429 bedeutet „zu viele Anfragen“. 403 bedeutet „verboten“. Verwechseln Sie diese nicht.
3. Retry-After einschließen
Informieren Sie Clients, wann sie es erneut versuchen können.
4. Ihre Limits dokumentieren
Machen Sie Ratenbegrenzungen in der Dokumentation sichtbar.
5. Verschiedene Stufen anbieten
Kostenlose Stufe: niedrige Limits. Bezahlte Stufe: höhere Limits.
6. Ratenbegrenzung nach Benutzer, nicht IP
Pro-Benutzer-Limits sind genauer und fairer.
7. Bursts erlauben
Token-Bucket ermöglicht angemessene Bursts, ohne den normalen Gebrauch zu bestrafen.
8. Ratenbegrenzungs-Hits überwachen
Verfolgen Sie, wie oft Clients Ratenbegrenzungen erreichen. Hohe Raten deuten auf Probleme hin.
9. Ratenbegrenzungsstatus-Endpunkt bereitstellen
GET /v1/rate-limit
200 OK
{
"limit": 100,
"remaining": 45,
"reset": 3540
}
10. Ratenbegrenzung testen
Verwenden Sie Apidog, um das Verhalten der Ratenbegrenzung vor der Bereitstellung zu testen.
Fazit
Ratenbegrenzung schützt Ihre API vor Missbrauch und gewährleistet eine faire Nutzung. Verwenden Sie den Token-Bucket-Algorithmus mit Standard-IETF-Headern (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset). Geben Sie 429 Too Many Requests mit dem RFC 9457 Fehlerformat zurück, wenn die Limits überschritten werden.
Modern PetstoreAPI implementiert die Ratenbegrenzung korrekt mit nutzerbezogenen Quoten, Standard-Headern und klaren Fehlermeldungen. Überprüfen Sie die Dokumentation für Implementierungsdetails.
Testen Sie Ihre Ratenbegrenzung mit Apidog, um sicherzustellen, dass sie unter Last korrekt funktioniert und Grenzfälle ordnungsgemäß behandelt.
Häufig gestellte Fragen
Welche Ratenbegrenzungen sollte ich festlegen?
Beginnen Sie konservativ: 100 Anfragen/Stunde für die kostenlose Stufe, 10.000/Stunde für die kostenpflichtige. Passen Sie die Werte basierend auf Nutzungsmustern und Infrastrukturkapazität an.
Sollte ich die Ratenbegrenzung nach IP oder Benutzer festlegen?
Ratenbegrenzung nach Benutzer (API-Schlüssel) für authentifizierte Anfragen. Verwenden Sie IP-basierte Ratenbegrenzung nur für öffentliche Endpunkte.
Was passiert, wenn ein Client die Ratenbegrenzung überschreitet?
Geben Sie 429 Too Many Requests mit dem Retry-After-Header zurück. Blockieren Sie den Client nicht dauerhaft – lassen Sie ihn es nach dem Zurücksetzen des Zeitfensters erneut versuchen.
Wie gehe ich mit Ratenbegrenzungen für Webhooks um?
Webhooks sind Server-zu-Server-Verbindungen, daher sollten die Ratenbegrenzungen höher sein. Erwägen Sie separate Limits für Webhooks im Vergleich zu API-Aufrufen.
Sollte ich interne Dienste einer Ratenbegrenzung unterziehen?
Ja, aber mit viel höheren Limits. Ratenbegrenzung verhindert Kaskadenfehler auch in internen Systemen.
Wie teste ich die Ratenbegrenzung?
Verwenden Sie Apidog, um mehrere Anfragen zu senden und 429-Antworten, Ratenbegrenzungs-Header und das Zurücksetzungsverhalten zu überprüfen.
Was, wenn meine API hinter einem CDN liegt?
CDN-Caching reduziert die Last, aber Sie benötigen weiterhin Ratenbegrenzung für Cache-Fehltreffer und POST-/PUT-/DELETE-Anfragen.
Wie implementiere ich Ratenbegrenzung über mehrere Server hinweg?
Verwenden Sie einen gemeinsamen Datenspeicher (Redis, Memcached), um Ratenbegrenzungen über alle Server hinweg zu verfolgen. Verwenden Sie keinen lokalen Speicher – dies funktioniert in verteilten Systemen nicht.