JAXenter: In deinem Workshop „API First mit Swagger & Co.“ auf dem API Summit stellst du den API-First-Ansatz vor. Was ist das genau?

Thilo Frotscher: Im Grunde genommen geht es bei dem Ansatz darum, mindestens das Design und ggf. auch die Entwicklung des APIs an den Anfang eines Projektes zu stellen. Der allererste Schritt sollte also sein, sich zu überlegen, wie das API im Detail aussehen und funktionieren soll, damit es möglichst universell einsetzbar und leicht verständlich ist. Dabei muss weder auf bestehende Systeme und deren Implementierung, noch auf mögliche Client-Technologien (Web-Client, Mobile App, etc.) Rücksicht genommen werden. Natürlich ist es oftmals so, dass man nicht wirklich auf der berühmten „grünen Wiese“ beginnt. In den meisten Fällen sind stattdessen schon irgendwelche bestehenden Systeme da. In diesem Fall geht es dann aber eben darum, diese bestehenden Fakten beim Design des APIs zu ignorieren.

JAXenter: Warum macht es Sinn, den Entwurf des APIs an den Beginn der Entwicklungskette zu stellen?

Thilo Frotscher: Der Ansatz soll sicherstellen, dass beim API-Design ausschließlich Aspekte wie Benutzbarkeit oder Erweiterbarkeit im Vordergrund stehen, und dass das API letztlich sehr universell einsetzbar ist.

Ohne den API-First Ansatz besteht dagegen die große Gefahr, dass das API – wenn auch unbewusst – stark an der Implementierung und den Anwendungsfällen bestehender Systeme ausgerichtet wird. Dies rächt sich spätestens dann, wenn nach Produktivnahme des APIs ein neuer Client oder ein neuer Einsatzzweck für das API hinzukommt und sich dann herausstellt, dass das API hierfür nicht universell genug entworfen wurde.

JAXenter: Systeme nachträglich an das API anzupassen, klingt erst einmal komplizierter als andersherum. Ist das tatsächlich so? Warum lohnt es sich, das System anzupassen und nicht das API?

Thilo Frotscher: Sicherlich wird in der Regel ein höherer Initialaufwand entstehen, wenn bestehende Systeme an ein neues API angepasst werden. Das API an diesen Systemen auszurichten, wäre oftmals der leichtere Weg. Aber mittelfristig macht sich dieser Aufwand praktisch immer bezahlt.

Hinzu kommt, dass die Einführung eines APIs in vielen Fällen auch an bestehende Systeme neue Anforderungen stellt, beispielsweise in den Bereichen Sicherheit oder Resilienz, und diese daher ohnehin anzupassen sind.

JAXenter: In deinem zweiten Workshop, „Fallstricke beim Design von Web APIs“ besprichst du Fallstricke beim Design und Entwicklung von Web APIs. Welche Fallstricke sind besonders eklatant und gefährlich?

Thilo Frotscher: Es ist sehr schwierig einzelne Aspekte herauszustellen, da es immer auch auf das konkrete Projekt und den jeweiligen Anwendungsfall ankommt. Meiner Meinung nach ist aber die allergrößte Falle vielleicht ohnehin gar nicht technischer Natur, sondern verbirgt sich an ganz anderer Stelle. Mithilfe der uns heute zur Verfügung stehenden Tools und Frameworks lassen sich erste Entwürfe eines APIs in wirklich sehr kurzer Zeit erstellen und als Prototyp in Betrieb nehmen. Dies verleitet aber auch – insbesondere im Management – sehr rasch zu dem Eindruck, dass das API ja im Prinzip schon fast fertig wäre. Genau das ist jedoch nicht der Fall.

Die Entwicklung eines sicheren, widerstandsfähigen, erweiterbaren und leicht benutzbaren APIs bedeutet einen beträchtlichen Aufwand.

Die Entwicklung eines sicheren, widerstandsfähigen, erweiterbaren und nicht zuletzt auch leicht benutzbaren APIs bedeutet trotz all der mächtigen Entwicklerwerkzeuge dennoch einen beträchtlichen Aufwand. Es müssen viele Aspekte bedacht und wohlüberlegt sein. Daher ist es wichtig, dass Entwicklerteams die hierfür notwendige Zeit auch bekommen. Falls dies nicht geschieht, wird man es bald bereuen. Denn sobald erste Clients ein API produktiv einsetzen, sind größere Änderungen nur noch schwierig umzusetzen. Daher sollte bereits die erste produktive Version des APIs eine gewisse Qualität aufweisen.

JAXenter: Wo liegen die Probleme meistens begründet – beim API-Betreiber oder beim API-Client?

Thilo Frotscher: Auf beiden Seiten gibt es gewisse Herausforderungen. Für API-Betreiber sind natürlich Themen wie Sicherheit, Widerstandsfähigkeit und Erweiterbarkeit von zentraler Bedeutung. Hinzu kommen Aspekte wie Dokumentation, Verständlichkeit und Benutzbarkeit. Auf Seiten der API-Clients sind ebenfalls einige Überlegungen zum Thema Sicherheit anzustellen. Darüber hinaus liegt ein Schwerpunkt auf der Frage, wie mit den Unwägbarkeiten des Netzwerks elegant umgegangen werden kann. Es geht also um Themen wie Timeouts, Wiederholung gescheiterter Requests, Fehlerbehandlung und Caching, aber auch um die Frage, wie man mehrere API-Aufrufe am besten parallelisiert, und wie man blockierende Aufrufe verhindert.

JAXenter: Vielen Dank für das Gespräch!