Klappe halten für bessere APIs
Fun fact: Wenn ich bis zur Nutzung deiner tollen internen API persönliche Treffen mit den Entwickler*innen in deinem Projektteam machen muss, dann ist die API vielleicht gar nicht so toll. Sondern eher Mist. Weil ausgerechnet hier weniger Redebedarf tatsächlich ein Zeichen für höhere Reife ist.
Es war mir stets schleierhaft, warum das so akzeptiert ist: Wenn Projekt A in großer Organisation eine Schnittstelle zu Projekt B aufbauen muss, dann schlägt die Stunde der “Abstimmungsmeetings”. Bonuspunkte des Todes für regelmäßige Abtast-Jour-Fixe, mit maximalem Teilnehmerkreis, damit “jeder abgeholt ist”. Und möglichst optimal mit Managementbeteiligung, Status-Quo-Onepagern in Powerpoint und Ampelsymbolik. Das ist eine riesige, zumeist vollkommen zweckfreie Verschwendung von Lebenszeit, um gar nicht vom Geld anzufangen.
Aber ich will nicht schimpfen: Was macht denn eine gute Schnittstelle (API) aus?
- Eine gute Schnittstelle ist systemübergreifend und zuverlässig verwendbar.
- Eine gute Schnittstelle verbirgt die Komplexität/Prozesse im Hintergrund.
- Eine gute Schnittstelle spart Zeit, und damit Geld.
- Eine gute Schnittstelle kann sich weiterentwickeln.
Klingt einfach, ist es aber nicht.
Wenn deine Schnittstelle nur mit bestimmter Technologie zu verwenden ist, ist sie nicht plattformunabhängig. Das bedeutet aber auch, dass deine Informationen an Technologie gebunden sind. Das ist schlecht, denn: Während sich da draußen die Welt rasend schnell weiter entwickelt, bleibst du stehen. Legacy, ich komme! Auch wenn es sich manche IT-Abteilungen nicht vorstellen können: Sprachen, Frameworks und Tools kommen und gehen. Daten hingegen sind wie Tafelsilber, die behält man.
Wenn der Konsument einer API Detailkenntnisse über die Abläufe im Zielsystem haben muss, damit die Kopplung funktioniert, dann müssen Anbieter und Konsument der Information ihre Abläufe stets synchron halten. Exponentiell wachsender Abstimmungsaufwand ist die Folge. Sowas sieht man häufig, wenn beim Design der API die bestehende Implementierung nicht sorgfältig genug vom Datenmodell getrennt wurde. Auch wenn es sich Entwickler “komplexer” Systeme kaum vorstellen können: Das verwenden ihrer Schnittstelle sollte trivial einfach sein.
Wenn deine Dokumentation veraltet ist, es keinen Beispielcode gibt, das Tooling nicht zeitgemäß ist - all das kostet den Konsumenten Zeit. Und wenn Fehler gefunden werden, weil die Qualität nicht gut ist, kostet es beide Entwicklerteams zusätzliche Zeit - Anbieter und Konsument. Die Einbindung einer API soll Zeit sparen. Das kann nur dann funktionieren, wenn gängige Konventionen eingehalten werden, Testsysteme jederzeit verfügbar sind und Dokumentation leicht auffindbar ist.
Und schließlich: Alles ist im Wandel. Wenn eine Modernisierung der API beim Anbieter dazu führt, dass die Konsumenten nachziehen müssen (und dazu meist weder Zeit noch Lust haben) dann wird die Modernisierung halt nicht gemacht. Andersherum gilt das genauso. Und schon veraltet deine API schneller, als du “software erosion” sagen kannst. Hier helfen übrigens Methoden wie Versionierung der Schnittstelle, vom Anbieter fertig bereitgestellte Clients und die Anwendung des Robustheitsgrundsatzes: “Sei streng bei dem, was du tust, und offen bei dem, was du von anderen akzeptierst”
Im Grunde ist es einfach: Eine Unternehmens-API sollte so leicht zu implementieren sein, dass man versucht ist, es “mal eben”, an einem Nachmittag in die Tastatur zu klimpern. Als Entwickler sollte man sich freuen, damit zu arbeiten. “Optimized for programmer happiness” - schon mal gehört? Aber das ist eine andere Geschichte…