Im Interview auf dem API Summit 2017 in Berlin stellt sich Thilo Frotscher den Fragen von Mirko Hillert (Entwickler Akademie).

Mirko Hillert: Du hast die Workshops „API First mit Swagger und Co.“ und „Fallstricke beim Einsatz von Web-APIs“ gehalten. Was genau verbirgt sich hinter dem Begriff „API First“?

Thilo Frotscher: Wir bekommen heutzutage nur noch sehr selten die Möglichkeit beziehungsweise die Chance, ein Projekt auf der grünen Wiese zu beginnen. Das bedeutet, dass noch keine existierenden Systeme da sind, die zu beachten sind. In der Regel ist nämlich irgendetwas immer schon da. Beispielsweise hat man schon eine Webanwendung für Onlinebanking, einen Onlineshop oder was auch immer das sein mag. Dann kommt zu einem späteren Zeitpunkt die Idee oder Anforderung auf, für die Anbindung anderer Systeme oder bestimmter Kanäle, mobiler Anwendungen, Apps und Sonstigem ein API hinzuzufügen. Oder gegebenenfalls auch ein Public-API, das zurzeit sehr im Trend ist. Da scheint es nahezuliegen, dieser bestehenden Anwendungen ein API hinzuzufügen und dort anzubauen. Das führt in der Regel dazu, dass im Resultat ein API vorliegt, das sich sehr stark an dem bestehenden System und an den Use Cases, die es gab, als man das bestehende System entwickelt hat, orientiert. Das bedeutet aber nicht, dass es auch notwendigerweise das Beste für die Clients bzw. Konsumenten ist, die dieses API am Ende bedienen sollen. Es kann sich nämlich gegebenenfalls um ganz andere Endgeräte und Kanäle handeln, über die sie benutzt werden sollen. Oder es handelt sich um neue Kunden oder Geschäftspartner, die ganz andere Anwendungsfälle für dieses API haben. Deswegen ist das Vorgehen, das API nur als Anhängsel einer bestehenden Anwendung zu bauen, keine gute Idee.

Empfehlenswert ist es, diesen API-First-Gedanken zu wählen. Als ersten Schritt in der Entwicklung sollte man sich also Gedanken machen, wie das API eigentlich aussehen soll, damit es gut benutzbar und verständlich ist, es einen guten Mehrwert und auch die Chance bietet, neuen Geschäftspartnern ganz neue Modelle aufzubauen. Das Ganze muss dann vollkommen losgelöst davon, was wir schon haben und welche Endgeräte wir uns vielleicht vorstellen, geschehen. Dabei ist es irrelevant, ob das ein Browser ist, der im Desktop läuft, oder ein mobiles Gerät. Im Anschluss an die Erstellung und das Designen des API kann man dann gegebenenfalls bestehende Systeme an dieses neue API anpassen und nicht umgekehrt. Darum geht es im Kern.

Mirko Hillert: Welche Standards oder Werkzeuge würdest du bei der Implementierung von APIs empfehlen?

Thilo Frotscher: Das ist eine Frage, die sehr häufig gestellt wird und die man leider nur sehr unbefriedigend beantworten kann. Es gibt eigentlich nicht sehr viele Standards und man ist ein wenig auf sich allein gestellt. Man wird auf viele Fragen, die sich stellen, eigene Antworten und Lösungen finden müssen. Deshalb würde ich eher empfehlen, sich daran zu orientieren, was andere schon gemacht haben. Das heißt natürlich nicht, dass man dies eins zu eins übernehmen sollte, aber es kann ein guter Startpunkt für die eigenen Überlegungen sein. Wenn wir über Standards reden, fällt einem natürlich erst einmal eine Sprache ein, um die API-Spezifikation zu erstellen. Eine Sprache, die also meinen Kunden/Konsumenten beschreibt, wie die Schnittstelle funktioniert, welche Operationen sie anbietet und wie die Datenstrukturen aussehen, die man über die Schnittstelle austauscht. Da gibt es sehr viele dieser Sprachen. In der Vergangenheit haben sich jedoch drei als besonders populär herausgestellt. Das war einerseits Swagger, API Blueprint und RAML. Diese haben alle verschiedene Stärken. Im Laufe der Zeit hat sich jedoch herausgestellt, dass Swagger das populärste Format war. Dazu hat sich in diesem Jahr eine Initiative gegründet, die OpenAPI Initiative. Dort haben sich viele der großen Hersteller versammelt und beschlossen, diese zu unterstützen. Das ist eine Anstrengung, um eine Spezifikationssprache zu standardisieren. Dabei dient Swagger als Startpunkt. Der OpenAPI-Standard ist also, etwas vereinfacht gesagt, ein Swagger 3.0. Gleichzeitig haben sich auch die Unternehmen, die die anderen beiden populären Sprachen (API Blueprint und RAML) in der Vergangenheit unterstützt und vorangetrieben haben, ebenfalls der Initiative angeschlossen. Dementsprechend ist zu erwarten, dass diese versuchen werden, auch die Stärken der anderen Sprachen in diesen neuen OpenAPI-Specification-Standard einfließen zu lassen. Das ist also tatsächlich mal ein kommender Standard.

Abseits davon gibt es relativ wenige Standards. Beispielsweise stellen sich viele die Frage: „Wie sollte mein API-Design aussehen? Wie sollte mein URL-Design aussehen? Wie kann ich filtern, wenn ich Produkte haben möchte, die nur einem bestimmten Kriterium entsprechen? Wie kann ich eine maximale Menge an Treffern zurückerhalten oder auch nur die ersten zehn? Da gibt es hundert verschiedene Wege, wie man das machen könnte, und es ist auch nicht schwer, sich solche auszudenken. Man stellt sich dennoch dabei die Frage: „Welcher wäre der beste Weg?“ Da gibt es keinen richtigen Standard. Aus meiner Sicht ist nur wichtig, dass man eine Einheitlichkeit schafft. Dass nämlich auch für den Verwender des API klar ist, dass wenn es an dem einen Endpunkt so funktioniert, zu erwarten ist, dass es an dem anderen Endpunkt genauso funktioniert und nicht anders. Man sollte für sich als Unternehmen oder als Team einen Standard entwickeln, wie man solche Dinge löst, aber dennoch gibt es keinen generellen Standard, wie es jeder macht. Das einzige, das ich an dieser Stelle empfehlen kann, ist, einfach im Netz zu schauen und Recherche zu betreiben. Es gibt viele, zum Teil auch große und populäre Unternehmen, die ihre eigenen API-Richtlinien ins Netz gestellt haben, also Vorschläge machen, wie man das lösen könnte. Es gibt beispielsweise auch so etwas wie OData. Das gefällt zwar nicht jedem so gut, aber ist ebenfalls ein Vorschlag, wie man solche API-Designs lösen könnte. Das muss man sich anschauen, sich daran orientieren, das als Startpunkt nehmen und übernehmen, was einem daran gefällt und das, was einem nicht gefällt, entsprechend anpassen.

Mirko Hillert: Du begleitest viele Kunden in Projekten? Welche Schwierigkeiten siehst du bei der Nutzung und dem Einsatz von Web-APIs?

Thilo Frotscher: Die erste Schwierigkeit, die auftritt, ist interessanter Weise nicht mal technischer Natur. Sie liegt darin, dass wir glücklicherweise heutzutage sehr gute Werkzeuge und Frameworks haben, die wir benutzen können und mit denen es sehr schnell geschafft ist, einen Prototyp eines API als Anbieter oder auch eines API-Clients zu erstellen. Da braucht man nur noch ein paar Zeilen Code schreiben, dann ist man sehr schnell fertig und kann bereits etwas zeigen. Das ist sehr gut und hilfreich, wenn es gerade bei dem API-First-Gedanken darum geht, mit seinen Kunden beziehungsweise Geschäftspartnern in einem agilen Prozess in kurzen Iterationen einen Prototyp zu erstellen und ihnen zu zeigen: „Schaut mal, ist das das, was ihr euch vorstellt? Könnt ihr das gut benutzen? Was bräuchtet ihr zusätzlich? Was braucht ihr eher nicht?“ Dann macht man eine neue Version und kann diese wieder schnell bereitstellen. Dafür gibt es tolle Tools, Werkzeuge und Onlineplattformen zur Zusammenarbeit, dass man so eine API-Spezifikation quasi einfach in einem Repository committet. Dann wird automatisch im Hintergrund ein Prozess gestartet, der MockServer und Dokumentationen generiert – da gibt es tolle Sachen. Aber das führt leider auch dazu, dass der Eindruck entsteht, oftmals auch in Richtung des Managements, dass man im Prinzip schon fertig ist, weil alles so schnell geht, so toll aussieht und man es ja schon zeigen kann. Tatsächlich ist man aber noch lange nicht fertig und man erkennt, dass sich viele Herausforderungen bei der Entwicklung von letztlich einem verteilten System mit Netzwerkkommunikation einstellen.

In dem Workshop geht es darum, darauf hinzuweisen, dass man sich nicht verleiten lassen darf zu denken, ein API könnte man ganz schnell mal ins Netz stellen, sondern aufzuzeigen, welche Herausforderungen es sowohl für den Anbieter also auch für den Konsumenten eines API gibt. Zudem soll darauf aufmerksam gemacht werden, welche Gedanken man sich bei der Implementierung machen muss, um dann nicht später mittelfristig in die Falle zu tappen, sondern rechtzeitig an solche Dinge zu denken.
Mirko Hillert: Thilo, vielen Dank für das Interview.

Interviewt von: Mirko Hillert

Mirko Hillert verantwortet seit 2007 als Leiter der Entwickler Akademie den Trainingsbereich bei Software & Support Media. Er studierte Betriebswirtschaft an der Westsächsischen Hochschule Zwickau und der Universidad Valencia sowie Marketing an der Westfälischen Wilhelms-Universität Münster. Als ehemaliger Dozent und Ausbilder für Managementprozesse treibt er seit vielen Jahren die fundierte Aus- und Weiterbildung von Entwicklern und Softwarearchitekten im IT-Markt voran, unter anderem mit innovativen Eventformaten und hochwertigen Trainingsinhalten.