Was ist API-Sprawl? Definition, Ursachen und Gegenmaßnahmen

Was ist API-Sprawl?

API-Sprawl ist das unkontrollierte Wachstum von APIs in einer Organisation: Die Zahl der APIs, Versionen und Endpunkte wächst schneller, als das Team sie finden, dokumentieren, absichern und stilllegen kann. Typische Anzeichen: Niemand kann alle produktiven APIs auflisten, mehrere Teams haben fast identische Endpunkte gebaut, und die Security stößt im Audit auf undokumentierte. Das Problem sind nicht viele APIs, sondern viele ungesteuerte APIs.

Warum es dazu kommt

Sprawl ist eine Nebenwirkung des Wachstums. Microservices, Drittanbieter-Integrationen, interne Tools, Mobile-Backends, Partner-APIs und alte Systeme, die noch laufen, vergrößern die API-Oberfläche, und jedes Team liefert, was es braucht. Ohne gemeinsames Inventar oder Prüfschritt sieht niemand das Gesamtbild. Interne APIs wuchern am schnellsten, weil sie weniger geprüft werden; siehe interne APIs.

Die vier Arten von Sprawl

Dokumentations-Sprawl

APIs existieren, aber ihre Doku fehlt oder ist veraltet. Entwickler suchen den richtigen Endpunkt, und die OpenAPI-Spezifikation passt nicht mehr zum Code. Lösung: Spezifikation aus dem Code erzeugen (oder umgekehrt) und in der CI prüfen.

Doppelte und überlappende APIs

Drei Teams bauen drei "Nutzer anlegen"-Endpunkte, weil keines die anderen kannte, jeweils mit leicht anderer Validierung. Lösung: ein durchsuchbarer Katalog und die Regel, vor dem Neubau dort nachzusehen.

Schatten-APIs

APIs, die Gateway, Security-Review oder Monitoring umgehen: mal ein Test-Endpunkt, der in Produktion gelandet ist, mal ein bewusster Umweg. Sie sind das größte Sicherheitsrisiko, weil niemand Authentifizierung, Rate Limits und Daten im Blick hat. Lösung: API Discovery aus echtem Traffic und Gateway-Logs, abgeglichen mit dem Katalog.

Zombie-APIs

APIs, die niemand mehr aufruft, die aber weiterlaufen, Patches brauchen und Daten offenlegen. Lösung: Nutzungsdaten pro Endpunkt und ein geordneter Rückbau; siehe API-Deprecation.

Warum API-Sprawl teuer ist

• Sicherheitsrisiko: Ungesteuerte APIs haben eher keine Authentifizierung, kein Rate Limiting oder keine Eingabeprüfung. Siehe API-Sicherheit.
• Doppelte Arbeit: Ein Fehler, der in einer Kopie behoben ist, bleibt in den anderen offen.
• Langsames Onboarding: Neue Entwickler lernen, was es gibt, von Kollegen statt aus einem Katalog.
• Compliance-Risiko: Audits fragen, wohin personenbezogene Daten fließen. Für unbekannte APIs lässt sich das nicht beantworten.
• Betriebskosten: Jeder laufende Dienst verbraucht Rechenleistung und Observability-Budget, auch die ungenutzten.

So bekommen Sie Sprawl in den Griff

1. Ein Katalog. Ein Register aller APIs mit Verantwortlichem, Spezifikation und Status. Bauen Sie es aus Code oder Gateway-Traffic auf, denn von Hand gepflegte Listen veralten.
2. Über ein Gateway routen. Ein zentraler Eingang liefert Ihnen eine Aufzeichnung aller APIs und Konsumenten.
3. Erst den Vertrag schreiben. Spezifikation vor dem Coden prüfen, wie im API-First-Ansatz.
4. Nutzung pro Endpunkt erfassen. Kein Traffic über einen festgelegten Zeitraum löst eine Deprecation-Prüfung aus.
5. Eintrittsregeln setzen. Eine neue API braucht Katalogeintrag, Spezifikation, Authentifizierung und einen benannten Verantwortlichen, bevor sie Traffic bekommt.

API-Sprawl und Monitoring

Ein Katalog sagt, was existieren soll; API-Monitoring sagt, ob es funktioniert. Das API-Monitoring von LoadFocus kann eine OpenAPI-3.x- oder Swagger-2.0-Spezifikation importieren und legt pro Operation einen Monitor an. So bekommt eine katalogisierte API Verfügbarkeits-, Statuscode- und Antwortzeit-Prüfungen, mit Alarmen an E-Mail, Slack, Microsoft Teams, Discord, PagerDuty, Opsgenie oder einen generischen Webhook. Das deckt die APIs ab, die Sie kennen; unbekannte findet es nicht, das ist Aufgabe von Discovery und Gateway-Logs. Zur Werkzeugauswahl siehe die besten API-Monitoring-Tools und wie API-Monitoring Ihrem Unternehmen hilft (beide englisch).

Häufige Fehler

• Neue APIs verbieten. Teams umgehen das Verbot. Machen Sie stattdessen den gesteuerten Weg zum einfachen Weg.
• Ein Katalog, den niemand pflegt. Ein veralteter Katalog ist schlimmer als keiner, weil man ihm vertraut.
• Zählen statt steuern. Messen Sie den Anteil des Produktions-Traffics über katalogisierte APIs, nicht die Gesamtzahl.
• Nicht-REST-APIs vergessen. GraphQL, gRPC, Webhooks und Event-APIs gehören zur Oberfläche.
• Drittanbieter-APIs ignorieren. Auch die externen APIs, von denen Sie abhängen, gehören in den Katalog.
• Alte Versionen weiterlaufen lassen. Ohne Abschaltdatum bleiben v1, v2 und v3 alle am Leben.

Häufige Fragen: API-Sprawl

Wie viele APIs sind zu viele?

Nicht die Zahl ist das Problem, sondern Auffindbarkeit und Steuerung. Eine nützliche Kennzahl ist der Anteil des Produktions-Traffics über katalogisierte APIs mit Verantwortlichem.

Ist API-Sprawl nur ein Microservices-Problem?

Nein. Auch Monolithen wuchern, durch interne Module, undokumentierte Endpunkte und Skripte, die davon abhängen. Microservices verschärfen es, weil jeder Service eine weitere API-Oberfläche ist.

Worin unterscheidet sich API-Sprawl von technischen Schulden?

Es ist eine bestimmte Art technischer Schulden: Die API-Oberfläche wächst schneller, als man sie steuern kann. Technische Schulden umfassen auch veralteten Code, Frameworks und Architektur.

Wie findet man Schatten-APIs?

Vergleichen Sie, was der Katalog sagt, mit dem, was tatsächlich Traffic erhält. Nutzen Sie Gateway-Logs, Load-Balancer-Logs oder passive Traffic-Analyse und lassen Sie Verantwortliche jeden unbekannten Endpunkt übernehmen oder stilllegen.

Wie hängt API-Versionierung mit Sprawl zusammen?

Jede laufende Version ist eine weitere API, die gesichert und gepflegt werden muss. Veröffentlichen Sie für jede Version ein Deprecation-Fenster und setzen Sie es durch.