Warum viele APIs eher Marketingversprechen als Produkt sind

API-First ist oft nur ein Märchen

Baron Münchhausen und die Mär von „API-First“.

Das Zauberwort API-First steht mittlerweile in fast jedem Pitch-Deck und jeder IT-Strategie. Die Realität in der Codebasis ist allerdings oft eher „API-Irgendwann“. Wer schon einmal versucht hat, eine vermeintlich moderne Cloud-Lösung anzubinden, kennt das Szenario: Die Marketingfolien versprechen nahtlose Integration mittels REST-API. Aber die technische Dokumentation liefert Fragmente.

Du startest die Implementierung der Schnittstellenlösung und stößt auf Endpunkte, die ins Leere laufen. Auf Fehlermeldungen, die mehr Rätsel sind als Diagnose. Auf Datenstrukturen, die nichts mit der Spezifikation zu tun haben. Auf einen Support, der sich rausredet.

Und hier liegt die eigentliche „API-Lüge“:

APIs werden oft nicht als eigenständiges Produkt umgesetzt, sondern als technisches Abfallprodukt der Benutzeroberfläche. Das ist diametral zum Versprechen, weil man sich ja „API-First“ auf die Fahne geschrieben hat.

Aber oft existiert in der API schlicht nichts, was für das eigene Frontend gerade nicht benötigt wird. Oder schlimmer: Es existiert, wurde aber seit drei Versionen nicht mehr gepflegt, weil kein Stakeholder direkt draufschaut.

Das ist kein technisches Versehen. Das ist ein strukturelles Defizit im Produktmanagement und ein großes Ärgernis für uns als Schnittstellen-Entwickler. Eine API ist keine bloße „Leitung“ für Daten. Sie ist ein verbindlicher Vertrag zwischen Anbietern und Nutzern. Wer diesen Vertrag bricht – durch mangelnde Dokumentation oder unangekündigte Breaking-Changes –, der zerstört Vertrauen und bindet wertvolle Entwicklerressourcen in unnötigem Reverse Engineering. Eine echte API erfordert echtes Product-Ownership, Versionierung und die gleiche Sorgfalt wie das GUI und die Datenbank. Alles andere ist nur eine offene Tür zu einer weiteren IT-Baustelle.

Natürlich gibt es rühmliche Ausnahmen, aber gefühlt mindestens genau so viele verlogene Konstrukte. Im letzten Kick-Off: Ein geheimer Zusatz-Parameter für den Mandanten, Endpunkt anders als in der Swagger-Doku, nicht implementierte Funktion trotz Doku, seit 2 Jahren abgelaufenes Zertifikat – und so weiter und so fort.

Wie erlebst du die Qualität aktueller APIs – sind wir auf dem Weg zur Besserung oder stagniert der Standard?