Eine API, die niemand nutzen will, hat keinen Wert. Eine, die niemand nutzen kann, auch nicht.
APIs werden oft rein technisch gedacht, im Sinne von wir brauchen einen Endpoint fuer X. Das reicht nicht. Eine API, die langfristig Wert liefert, muss als Produkt gedacht werden: Wer sind die Nutzer, interne Entwickler, externe Partner, Drittanbieter? Was brauchen sie, und was frustriert sie an bestehenden Schnittstellen?
Diese Fragen klingen nach Product Management. Das sind sie auch.
API-First gegen API-Later
API-First bedeutet, zuerst das Design festzulegen, dann zu implementieren. Der Vertrag in Form einer OpenAPI-Spec wird vorab definiert, alle Stakeholder stimmen zu, dann wird gebaut. Das verhindert Breaking Changes nach dem ersten Release. API-Later, der haeufigere Fall, baut zuerst, bis etwas laeuft, und dokumentiert erst danach, was entstanden ist, mit dem Risiko, dass jeder Design-Fehler nachtraeglich gepatcht werden muss.
Governance: wer entscheidet was
Wer darf das Schema aendern, wie werden Breaking Changes kommuniziert, wer verantwortet die Dokumentation? Ohne klare Antworten waechst jede API frueher oder spaeter zur Wildnis.
Interne und externe APIs unterscheiden
Interne APIs fuer Service-zu-Service-Kommunikation legen den Fokus auf Performance und schnelle Iteration. Externe APIs fuer Drittentwickler brauchen dagegen Stabilitaet, Versionierung und ausfuehrliche Dokumentation.
Checkliste: Zielgruppen der API klar definiert, API-First oder API-Later bewusst entschieden, Governance-Prozess fuer Aenderungen definiert, Versionierungsstrategie festgelegt, Developer Experience als Qualitaetskriterium verankert.
Ein Beispiel aus der Praxis
Ein Unternehmen baute eine API zunaechst rein reaktiv, Endpoint fuer Endpoint, je nachdem, welches interne Team gerade etwas brauchte. Nach zwei Jahren existierten fuer aehnliche Anwendungsfaelle drei unterschiedliche Endpunkte mit leicht abweichender Antwortstruktur, weil nie ein uebergreifendes Konzept bestand. Ein nachtraeglich eingefuehrtes API-Governance-Board, das jede neue Endpoint-Anfrage kurz gegen bestehende Muster prueft, verhinderte seither, dass sich diese Fragmentierung weiter fortsetzte, ohne dabei neue Entwicklungen spuerbar zu verlangsamen.
API-Strategie fuer euer Projekt entwickeln? markom.digital hilft bei der strategischen Planung von API-Architekturen, mit Fokus auf Nutzbarkeit und Langlebigkeit.
