Unabhängiger Vergleich · keine bezahlten Platzierungen
Startseite / Blog / Ratgeber / Starten Sie eine öffentliche API: Legen Sie Grenzen fest, bevor Kunden eintreffen

Starten Sie eine öffentliche API: Legen Sie Grenzen fest, bevor Kunden eintreffen

Eine öffentliche API ohne Ratenbegrenzung, Kontingente und Beobachtbarkeit führt immer dazu, dass die Datenbank überlastet wird – oft durch einen einzelnen „vertrauenswürdigen“ Client, der die Schleife schlecht verarbeitet.

Redaktion Hébergeurs.eu 4 Min. Aktualisiert 23 Mai 2026

Ein SaaS-Herausgeber öffnet seine API für Integratoren. Zwei Wochen später synchronisiert ein ERP-Partner über ein Wochenende hinweg 200.000 Produktblätter in einer Schleife – ohne Paginierung. Montagmorgen: PostgreSQL-Datenbank mit 100 % CPU, Cloud-Rechnungen verdreifacht, Hauptkunden im Timeout. Die Obduktion ergab, dass es keine Quote, keine Warnung, keine dokumentierten 429 gab.

Das Öffnen einer öffentlichen API bedeutet nicht, dass Endpunkte offengelegt werden. Es geht darum zu akzeptieren, dass Unbekannte Ihre Ladung kontrollieren – manchmal aus Bosheit, oft aufgrund eines Integrationsfehlers. Grenzwerte sollten vor dem ersten Kunden bestehen, nicht nach dem ersten Ausfall.

Die vier nicht verhandelbaren Schutzmaßnahmen

LeitplankeOhne ihnMinimale Rentabilität
AuthentifizierungAnonymer MissbrauchAPI-Schlüssel oder OAuth2-Client-Anmeldeinformationen
RatenbegrenzungEndlosschleifenPer Schlüssel + per Backup-IP
KontingenteEin Kunde monopolisiertDokumentierte Anforderung/Tag + Burst/Min.
BeobachtbarkeitBlinde ObduktionStrukturierte Protokolle, P95-Metriken, 429/5xx-Warnungen

Eine API ohne 429 ist eine API, die Höflichkeit und Robustheit verwechselt. Eine ordnungsgemäße Entlassung schützt alle.

Ratenbegrenzung: Strategie nach Stufe

Beispiel für ein öffentliches Netz:

StufeBurst/minKontingent/TagTypische Verwendung
Sandkasten301.000Entwicklung, Test
Standard12050.000KMU-Integrator
Partner600500.000ERP, Marktplatz

Umsetzung:

  • Nginx limit_req_zone für globale IP-Obergrenze.
  • Redis-Zähler von „api_key“ für tägliche Kontingente.
  • Gateway (Traefik, Kong) zur Zentralisierung ohne erneute Bereitstellung der App.

Antworten Sie mit 429 mit „Retry-After“ und explizitem JSON-Body – und lassen Sie den Client nicht eine TCP-Zeitüberschreitung erraten.

Technische Details finden Sie unter Ratenbegrenzung: Eine API schützen, ohne gute Clients zu bestrafen.

Hosting-Größe: Die Basis zählt mehr als die CPU-API

Eine „einfache“ API-Anfrage kann Folgendes kosten:

  • 1 indiziertes SELECT → 2 ms
  • 1 SELECT ohne Index + JOIN → 800 ms × 500 req/s → tot

Checkliste unten:

  1. Paginierung erforderlich (Limit max. 100, Cursor bevorzugt).
  2. Cache Redis für idempotente Lesevorgänge (Katalog, Repositorys).
  3. Verbindungspool (PgBouncer) – siehe Verbindungspool.
  4. Getrennte Worker starke Synchronisierung im Vergleich zur interaktiven API.
  5. Autoskalierung der Warteschlangentiefe, nicht nur der CPU.

Geteilt: Nein für seriöse öffentliche API. Mindest-VPS; Cloud mit Load Balancer von mehreren zahlenden Kunden.

Versionierung, Veraltung und Kommunikation

Technische Grenzen ohne Produktgrenzen = Schulden:

  • Präfix „/v1/“ eingefroren; Breaking Change = /v2/.
  • Kopfzeile „Sonnenuntergang“ und E-Mail 90 Tage vor der Auszahlung.
  • Vorfallstatus oder RSS-Seite – Integratoren lesen nicht immer internes Slack.

Beobachtbarkeit: Metriken, die vor Twitter alarmieren

  • p95/p99-Latenz pro Endpunkt (nicht nur Durchschnitt).
  • Rate 429 pro Taste – erkennt wackelige Integration vor der Sättigung.
  • Aktive DB-Verbindungen vs. maximaler Pool.
  • Top-Verbraucher: Wochentabelle der gierigsten Schlüssel.

Warnung, wenn p95 > Internes SLA für 5 Minuten oder wenn ein Schlüssel um 14:00 Uhr das Kontingent von 80 % überschreitet.

Der Gipfel: Der schlechteste Kunde ist derjenige, der einen Vertrag unterzeichnet hat

:::Höhepunkt Die kostspieligsten Missbräuche gehen nicht von Bots aus – sie kommen vom „strategischen“ Partner, dessen Synchronisierungsskript noch nie von Paging gehört hat. Ohne vertragliche und technische Ratenbegrenzung kann Ihr bester Kunde zum schlimmsten Vorfall werden. :::

Marketing will „Open API“. Die Finanzwelt will Vorhersehbarkeit. Der Betrieb muss flexible Wände vorsehen: hoch genug für gute Zwecke, sichtbar genug, um Fehler vor der Basis zu stoppen.

Entscheide dich und gehe ohne blinden Fleck voran

  1. Veröffentlichen Sie Limits + Beispiele 429 vor dem ersten Schlüssel.
  2. Auslastungstest mit „Schleifen-Client“-Szenario (nicht nur Happy Path).
  3. Redis + PgBouncer vor dem Partnerstart.
  4. Dashboard-Top-Konsumenten, die im ersten Monat jede Woche überprüft werden.
  5. Runbook: Schlüssel schneiden, schreibgeschützter eingeschränkter Modus, Status kommunizieren.

Vergleichen Sie VPS und Cloud in unserem Verzeichnis und Vergleich.

Häufig gestellte Fragen

Ist ab Version 1 eine Ratenbegrenzung erforderlich?

Ja – sogar bescheiden – um versehentliche Schleifen zu vermeiden und Quoten frühzeitig festzulegen.

Wo soll die Ratenbegrenzung erfolgen?

Nginx + minimaler API-Schlüssel; Gateway für erweiterte Richtlinien; Code für Geschäftsregeln.

Wie dimensioniere ich das Hosting einer API?

Spitzen pro Kunde, Ziel p95, DB-Kosten/Abfrage; Caching und Paging vor der horizontalen Skalierung.

Was ist vor dem Öffnen zu dokumentieren?

Beschränkungen nach Stufe, 429, Wiederholungsversuch nach, Abschreibung, Vorfallstatus.


Eine ausgereifte öffentliche API lehnt Anfragen ordnungsgemäß ab – bevor die Datenbank alle ohne Vorankündigung ablehnt.

Europäische Hoster vergleichen

Filtern nach Compliance, Standort und Einsatzzweck — dann die Datenblätter öffnen, um den echten Umfang zu prüfen.

Verzeichnis durchsuchen
Blog

Weiterlesen

Alle Artikel →