Programmierschnittstelle geht vor Code Was bedeutet API first für die Entwicklung?

Anbieter zum Thema

netfiles GmbH

Cloudgermany.de GmbH

Zuerst die API – für alteingesessene Coder mag das klingen, als wolle man das Pferd von hinten aufzäumen. „API first“ ist angesichts Microservice- und Cloud-native-Anwendungen aber ein Trend, der sich auf Dauer durchsetzen wird.

Das Konzept „API first“ begegnet einem in zunehmender Häufigkeit, meist begleitet von praxisnahen Lösungen wie Swagger und dem Paradebeispiel Zalando mit seiner ausführlichen API-Dokumentation. Und schon die Betonung des „first“ zeigt klar: Das war nicht immer so.

Verbreiteter war seit jeher die konkurrierende Herangehensweise „Code first“, die manch einem Entwickler auch deutlich logischer erscheinen dürfte – man erstellt ein monolithisches Projekt und wenn alles läuft, kümmert man sich (eventuell) um Schnittstellen. Für gewisse Projekte ist das auch nach wie vor eine plausible Vorgehensweise, nur dürften eben solche Projekte immer seltener werden.

Aber mal von vorn: Software-Projekte, letztlich also jedwede Programme, dienen der Datenverarbeitung – Daten werden eingelesen, verarbeitet und ausgegeben, das gute alte EDV-Grundprinzip EVA. Und schon hier zeigt sich im Grunde, dass Software nun einmal kein Selbstzweck ist, es geht um die Daten.

Baut man eine Datenbank auf, ist es zum Beispiel ziemlich selbstverständlich, zunächst ein Datenmodell zu definieren – sobald das einmal steht, lässt sich die eigentliche Anwendung mit Standardmitteln recht simpel aufbauen. Auch das ist im Grunde schon ein „Design first“-Ansatz, wie API first auch häufig genannt wird. Ganz so neu wie das Schlagwort ist das dahinterliegende Konzept also nicht.

Code first

Ganz klassisch könnte man einfach ein Pflichtenheft und/oder einen Anforderungskatalog erstellen und dann in einem geschlossenen Team beginnen, die nötigen Funktionen zu programmieren, Datenmodelle zu entwerfen, Mockups für UI und UX zu designen und irgendwann einen Prototyp präsentieren.

Sobald eine Grundfunktionalität steht, könnte man dann auch weitere Teams mit an Bord holen, die die Daten der Anwendung beispielsweise in einem anderen Bereich (anders) nutzen wollen. Man könnte ihnen auch irgendeinen Endpunkt einrichten, aus dem sich Daten in einem bestimmten Format ziehen lassen – und Team 2 würde dann eben das Beste daraus machen.

Das ist jetzt freilich etwas vereinfacht, aber im Grunde läuft es genau darauf hinaus: Man fängt an zu programmieren und entwickelt sein eigenes Projekt für die eigenen Anforderungen. Und wenn es dabei bleibt, ist auch alles gut. Bei einem klar definierten Zweck für einen klar definierten Anwendungsbereich lässt sich auf diese Art ziemlich fix eine Lösung entwickeln, die ihren Zweck erfüllt.

Doch genau dort scheitert es häufig und es hagelt nachträglich Probleme – denn bei fast jeder Anwendung findet sich irgendwann, irgendwo irgendjemand, der feststellt, dass man mit den Daten aus dem Programm doch etwas ganz Fantastisches anfangen könnte, wenn man sie nur mit eigenen Mitteln abfragen und verarbeiten könnte. Und dann wird es oft kompliziert.

Wie viele Beispiel gibt es allein in der Welt, bei denen formatierte Daten als rohe Streams erfasst und dann mit wahnsinnig komplexen regulären Ausdrücken in eine verarbeitbare Form gebracht werden? Das funktioniert und hat seinen Reiz im puristischen Ansatz, aber eine API würde das Leben deutlich einfacher gestalten.

API first

Genau das ist der wesentliche Gedanke hinter dem API-first-Konzept: Es geht um Daten – und die soll doch bitte jeder mit einem berechtigten Interesse nach eigenen Vorstellungen verarbeiten können. Dabei spielt es kaum eine Rolle, ob es um organisationsinterne Daten geht, die zum Beispiel sowohl Rechts- als auch Marketing- und Produktmanagement-Bereiche benötigen, oder um Daten und Projekte, die in die Welt entlassen werden.

Ein Beispiel zeigt deutlich, wie sehr ein Unternehmen von diesem Ansatz profitieren kann: Philips hat es mit seiner Smart-Home-Beleuchtung Hue in etliche Haushalte geschafft – anfangs vor allem dank sehr guter Hardware und cleveren Marketings. Mittelfristig dürften es aber das riesige App-Universum sein, das durch einzelne Entwickler, kleine Unternehmen, Partner und nicht zuletzt die Open-Source-Community entstanden ist.

Möglich ist die einfache Entwicklung von Apps, selbst mit grundlegenden Bash-Scripting-Skills, durch die simple API der Steuerzentrale, der Hue Bridge. Philips muss selbst nichts dafür tun – die wenigen Philips-eigenen Apps sind auch wirklich nicht das Gelbe vom Ei.

An dieser Stelle kommt dann gerne das nächste Schlagwort: Microservices. Es mag wieder eine Definitionsfrage sein, doch letztlich ist damit nichts weiter gemeint, als dass man rund um einen Bestand von Daten einzelne Dienste für klar definierte Zwecke baut – via API-Zugriff. Bei den meisten Anwendungen gibt es heute einfach jede Menge Stakeholder, die ein – mehr oder weniger – gleichberechtigtes Interesse an den Daten haben.

Angesichts dessen scheint es nicht sonderlich sinnvoll, eine monolithische App für einen Bereich zu entwickeln und alle anderen dann vor vollendete Tatsachen zu stellen. Also bietet es sich an, zuerst die API samt zugehöriger Datenmodellierung zu designen – ganz unabhängig von irgendwelchen Entwicklungsumgebungen oder gar Programmiersprachen.

Hier kommt der Teil ins Spiel, der API first vermutlich nicht jedem sofort schmackhaft macht: Man muss sich mit den anderen Stakeholdern einig werden, einen Vertrag schließen, wie die API aussehen soll. Das ist sicherlich kein einfacher Prozess und Code-first-Veteranen dürften ihn teils wohl als ziemlich unproduktiv wahrnehmen; schließlich gibt es bei API first deutlich mehr Management-Vorlauf vor der ersten Zeile Code. Doch das dürfte sich anschließend schnell ändern, aus zwei Gründen:

• Erstens können nach der API-Definition mehrere unterschiedliche, voneinander völlig unabhängige Teams parallel anfangen, Anwendungen zu programmieren – mit den gewünschten Mitteln, Sprachen und Prozessen. Im Falle von völlig offenen APIs gilt das dann natürlich ebenso für beliebige Dritte.

• Zweitens können Frameworks wie Swagger aus der API-Definition sogar eigenständig Anwendungen generieren – wenn auch nur bruchstückhaft. Dennoch: Aus einem relativ simplen API-Dokument lassen sich aus dem Swagger-Editor Clients und Server-„Stümpfe“ in diversen Sprachen exportieren, die für Tests oder Weiterentwicklungen herangezogen werden können.

Bei allen Hilfmittelchen darf man aber nicht vergessen: Die menschen- und maschinenlesbaren APIs müssen nichtsdestoweniger gepflegt und vor allem sehr gut dokumentiert werden – nicht unbedingt die Lieblingsaufgabe von (Code-nahen) Entwicklern.

Nur noch API first?

Möchte man ganz ketzerisch an das Schlagwort API first herantreten, könnte man sagen: Auch bei einer Anwendung, die ein einzelner Entwickler für sich ganz persönlich programmiert, stehen Datenmodell und API ganz am Anfang – nicht dokumentiert, nicht von außen erreichbar. Aber wie der eigene Code mögliche Nutzereingaben oder hinterlegte Daten einliest und verarbeitet, muss ja zumindest beim Coder im Kopf festgelegt sein.

Selbst wenn es nur ein simples Skript ist, das Textdateien verarbeiten soll, steht am Anfang die Frage: „Wie genau sind die Daten formatiert?“ Man könnte also meinen, das API-first-Prinzip sei weniger etwas völlig Neues als die Formalisierung, Ausgestaltung und Zugänglichmachung ganz normaler Denkprozesse.

Abseits solcher Gedankenexperimente lässt sich das API-first-Thema für die Praxis aber recht simpel zusammenfassen: Sobald Daten für viele verschiedene Stakeholder, inklusive Nutzer, mit völlig unterschiedlichen Anforderungsprofilen relevant sind, lohnt es sich, die API als das eigentliche Produkt zu begreifen, um das herum sich jeder seine Anwendung stricken kann. Soll hingegen nur eine sehr eng definierte Aufgabe von einer klar definierten Nutzergruppe erledigt werden, dürfte Code first nach wie vor der effizientere Prozess sein.

(ID:47550434)