Ein Application Programming Interface (API) lässt sich mit den Worten Anwendungs-Programmierschnittstelle beschreiben. Was leistet so eine Schnittstelle? Diese Schnittstelle eines Programmes steht anderen Programmen zur Anbindung an das schnittstellen-führende System bereit. Und zwar zwischen Programmen auf einem Betriebssystem ebenso wie über Betriebssystemgrenzen und -arten hinaus. Software-Entwickler und Programmierer usw. nutzen diese APIs – manchmal schreiben sie diese auch.
Ein API veranschaulicht
Wenn man zum Beispiel eine Grafik aus einem Dateimanager (Finder, Datei-Explorer etc.) per Drag-and-drop herauszieht und in Word-Dokument fallen lässt, sieht das selbstverständlich aus. Tatsächlich ist dies aber nur möglich, weil ein API dazu existiert. Um beim eben erwähnten Beispiel zu bleiben: Man hat zwei Anwendungen, den Dateimanager und ein Word-Programm. Und beide Programme greifen in diesem Fall auf ein API zu. In diesem Fall auf ein API des Betriebssystems. Eine Schnittstelle macht also die Programmgrenzen an dieser Stelle durchlässig. Konkreter: Eine Programmierschnittstelle beschreibt mit festen Regeln, was wie angesprochen und verarbeitet werden kann.
In der Regel zeichnet sich eine Schnittstelle durch ihre – hoffentlich gute – Dokumentation und Stabilität in der Zeit aus. Der interessierte Leser verschafft sich hier einen Überblick: Clipboard für Windows und Pasteboard für MacOS. Unschwer zu erkennen, dass selbst so simpel erscheinende Operationen wie Copy-und-paste sehr umfänglich dokumentiert sind und viele Seiten füllen. Andere ebenso selbstverständlich erscheinende Programmierschnittstellen stellen zum Beispiel das DOM eines HTML-Dokuments oder die Art und Weise dar, wie man Kartendienste ansprechen kann.
API Standards müssen auch eingehalten werden
Ein gemeinsamer Ansatz zur Standardisierung von APIs innerhalb eines Unternehmens besteht darin, ein Team von API-Experten (Architekten, Entwickler usw.) zusammenzustellen und umfassende API-Richtlinien erstellen zu lassen. Dies ist eine großartige Initiative und führt Teams dazu, wichtige Fragen zu stellen und Regeln zu implementieren, um sicherzustellen, dass die APIs sowohl sicher, benutzerfreundlich als auch skalierbar sind. Dies kann sich jedoch schnell zu einem massiven Unterfangen entwickeln und die bloße Definition von Richtlinien stellt noch nicht deren Einhaltung sicher.
Europas führende Online-Modeplattform mit mehr als 15.000 Mitarbeitern, hat ihre RESTful API Guidelines auf GitHub veröffentlicht und können hier gelesen werden: Zalando RESTful API and Event Scheme Guidelines. Dies ist ein ausgezeichnetes Beispiel für API-Richtlinien, da sie explizit vorschreiben, wie RESTful APIs bei Zalando entwickelt werden sollten, und Beispiele, Vorschläge sowie Dos and Don’ts enthalten. Diese API-Richtlinien umfassen über 96-Seiten-PDF und haben höchstwahrscheinlich enorm viel Aufwand gekostet. Während die Bemühungen für die Zusammenstellung eines 96-seitigen Regelwerks gelobt werden sollten, besteht die eigentliche Arbeit darin, sicherzustellen, dass die Richtlinien in allen ihren Apps und Microservices umgesetzt werden. Solche Richtlinien zu haben ist wichtig, aber ihre Durchsetzung in einem Unternehmen – insbesondere in einem global agierenden – kann nahezu unmöglich sein.
Die Mehrheit der im umfangreichen Dokument aufgeführten Richtlinien einfach zu verstehen oder zu kennen, ist eine Herausforderung. Dies war sicher ein Schlüsselfaktor für den Erfolg von Zalando gewesen, als sie begannen, ihre Microservices-Architektur auf AWS und anderen Clouds zu skalieren und einzusetzen – die meisten Unternehmen sind nicht so digital ausgereift und werden es vielleicht nie sein. Doch mittlerweile ist die Welt der APIs gereift, Best Practices wurden von führenden Unternehmen wie Zalando veröffentlicht und Standards wie die OpenAPI Initiative gewinnen an Popularität und Akzeptanz.
Durch die Abstraktion der eigentlichen Erstellung der API und die automatische Implementierung des OpenAPI-Initiative-Standards können Teams schneller Ergebnisse liefern, ohne durch eine 96-seitige API-Richtlinie blättern zu müssen, um doppelt oder dreifach zu überprüfen, ob ihr Produkt alle Anforderungen erfüllt. Darüber hinaus müssen Unternehmen die Richtlinien nicht mehr gegenüber internen und externen Entwicklungsteams oder Systemintegratoren durchsetzen.
Ein strenger API-Standard kann fast jeden Business-Anwendungsfall erfüllen
Die Erstellung einer neuen API gibt Unternehmen die Möglichkeit, schnell MVPs und Prototypen zur Validierung von Use-Cases zu erstellen.
Bei jeder Regel gibt es immer eine Ausnahme und ein strenger API-Standard kann nicht jeden Business-Anwendungsfall erfüllen – aber er wird wahrscheinlich eine Mehrheit lösen. Wenn ein Projekt ein bestimmtes Protokoll benötigt, das nicht einem RESTful-API-Standard wie GraphQL entspricht, dann können diese individuell angesprochen werden. Für die meisten Anwendungsfälle wird eine standardisierte RESTful API die Arbeit erledigen.