Mit Thilo Frotscher, freiberuflicher Softwarearchitekt und Trainer, hat entwickler.de im Vorfeld des API Summit (19. – 21.06. in München) über die Herausforderungen für Entwickler bei API-Designs gesprochen und nach einigen der gängigsten Hürden dabei gefragt.

Herr Frotscher, Entwickler holen sich mit APIs eine komplett neue Ebene in Projekte – wie sehr verändert das den ihren Alltag?

Thilo Frotscher: Dies bringt eine Menge von Veränderungen mit sich. Die einschneidendste ist aber vielleicht, dass durch die Anbindung (potenziell zahlreicher) anderer Systeme über Web-APIs plötzlich die vielfältigen Herausforderungen verteilter Systeme auf Entwickler zukommen. Wer bislang überwiegend monolithische Anwendungen entwickelt hat, die im Wesentlichen nur mit einer Datenbank und bestenfalls noch mit ein bis zwei internen Backend-Systemen kommunizierten, der muss Anwendungsentwicklung nun ganz neu denken.

Web-APIs erfreuen sich immer größerer Beliebtheit; aber gerade wenn wir vom Web reden, dürfen wir nicht außer Acht lassen, dass es zahlreiche Abhängigkeiten gibt, die man sich an Bord holt. Was sind die gängigsten Strategien, um schlechten oder gar ausfallenden Netzen entgegenzuwirken?

Frotscher: Da gibt es eine ganze Reihe von Maßnahmen, die in Frage kommen.

Zunächst sollte man sich sinnvolle Werte für Time-outs überlegen und eine Strategie für Retries entwerfen. Besonders letztere ist oftmals sehr spezifisch. Es lässt sich nur selten verallgemeinern, ob oder wie häufig ein Retry versucht werden sollte. Tatsächlich ist es durchaus nicht unüblich, unterschiedliche Retry-Strategien für die Operationen eines API einzusetzen.

Darüber hinaus haben sich einige Softwarepatterns etabliert, die dabei helfen sollen, die Resilienz einer Anwendung zu verbessern. Zu den bekanntesten dieser Patterns zählen beispielsweise Circuit Breaker oder Bulkhead. Weiterhin kann man gegebenenfalls überlegen, sämtliche synchrone Kommunikation in separate Threads auszulagern, also nebenläufig durchzuführen. All dies stellt aber nur eine Auswahl von möglichen Maßnahmen dar. Und natürlich müssen nicht alle auch immer eingesetzt werden. Es sollte von Fall zu Fall entschieden werden, welche Maßnahmen jeweils sinnvoll sind.

Web-APIs bieten zahlreiche weitere Stolpersteine. Auf welche Probleme kann man bei der Entwicklung eines API treffen?

Frotscher: Es gibt vielfältige Themen, die bedacht werden sollten. Ganz besonders wichtig sind natürlich Sicherheitsaspekte. Weitere Themen sind etwa Testbarkeit, Dokumentation, Versionierung oder die Umsetzung lang laufender Prozesse. Für all diese Aspekte existieren gangbare Lösungen oder Strategien. Zu Stolpersteinen werden sie in aller Regel vor allem dann, wenn sie nicht oder zu spät betrachtet werden.

Folgt man dem API-First-Ansatz, dann sollten Konsumenten wie liefernde Systeme erst entstehen, wenn das API fertig designt ist. Aus der Praxis gesprochen: Ist das bei der Masse bestehender Systeme überhaupt möglich?

Frotscher: Ich denke, wie so viele andere Dinge muss man auch diesen Aspekt nicht unbedingt in schwarz und weiß denken. Es gibt auch hier eine Menge Grautöne.

Im Zuge eines agilen Vorgehens können gegebenenfalls auch schon erste Entwicklungsschritte vor Abschluss des API-Designs erfolgen. Es wäre in diesem Zusammenhang auch zu definieren, wann ein API überhaupt „fertig designt“ ist oder ob es das jemals sein kann. Und ob der Konsument ein komplettes System ist oder nur eine Komponente. Nicht zuletzt kommt es auch sehr darauf an, ob es sich um ein API handelt, das der Öffentlichkeit zur Verfügung steht, oder um ein internes Web-API.

Auf dem API Summit halten Sie zwei Workshops – „API First mit Swagger und Co.“ sowie „Fallstricke beim Design von Web-APIs“. Was hoffen Sie, den Teilnehmern mitzugeben?

Frotscher: APIs sind mit aktuellen Frameworks und Entwicklerwerkzeugen im Handumdrehen erstellt – zumindest erste Prototypen. Dies verleitet jedoch in gewisser Weise dazu, sich zu wenige konzeptionelle Gedanken zu machen.

Oftmals geschieht dies auch als Resultat einer gewissen Erwartungshaltung des Managements, wenn dort die Ansicht vorherrscht, dass für APIs nur sehr wenig Entwicklungszeit notwendig ist. Als Folge besteht ein erhöhtes Risiko, nicht ausgereifte APIs in Betrieb zu nehmen. Diese Unreife kann sich sowohl auf das API selbst beziehen, d. h. auf seine Benutzbarkeit, Verständlichkeit und Wartbarkeit, aber ebenso auch auf seine technische Umsetzung, also beispielsweise auf Widerstandsfähigkeit und Antwortzeiten unter Last. Die beiden Workshops sollen dabei helfen, das Bewusstsein dafür zu schärfen, welche Aspekte beim Design und bei der Implementierung von Web-APIs bedacht werden sollten.

Mehr Details zum Thema gibt es von Thilo Frotscher in seinen Workshops API First mit Swagger & Co. und Fallstricke beim Design von Web APIs auf dem API Summit.