5 Experten verraten Tipps & Tricks - Teil 2

Expertencheck: APIs implementieren – worauf es dabei ankommt!

Hartmut Schlosser

© Shutterstock / TierneyMJ

APIs are eating the digital world: Von öffentlichen APIs, die es Unternehmen ermöglichen, ihr Cloud- und SaaS-Geschäftsmodell zu skalieren, bis hin zu Software-Architekturen, bei denen REST-APIs und JSON unverzichtbar sind – Programmierschnittstellen sind heutzutage allgegenwärtig. Anlässlich der APIcon 2018 haben wir 5 Experten gefragt, weshalb die API Economy derzeit Konjunktur hat und wie man API-basierte Projekte erfolgreich gestaltet.

Im ersten Teil unseres großen API-Expertenchecks ging es darum, wie APIs Unternehmen und ganze Branchen verändern. Im zweiten Teil schauen wir auf die konkrete Umsetzung: Worauf kommt es bei der Einführung von APIs an? Welche Herausforderungen gilt es zu meistern? Mit welchen Themen sollte man sich beschäftigen?

Wie startet man ein API-Projekt?

Bei der Einführung einer API stellen sich gleich mehrere Fragen: Startet man technologisch, oder muss man zuerst neue Prozesse etablieren? Braucht es zunächst ein ausgefeiltes Konzept zum API Management, oder ist der MVP-Ansatz hier besser: erstmal klein starten, Feedback einholen, weiterentwickeln?

JAXenter: Wie sollte man ein API-basiertes Projekt angehen? 

Die API-Experten

Arne Limburg – API-Experte bei der open knowledge GmbH und Trainer im Enterprise- und Microservices-Umfeld.

Michael Hofmann – freiberuflicher Entwickler und Coach in den Bereichen Softwarearchitektur, Java Enterprise und DevOps.

Tom Hombergs – Berater, Coach und Architekt bei der adesso AG mit Fokus auf verteilten Architekturen und Spring Boot.

Christoph Wiechmann – berät Kunden auf ihrem Weg ins digitale Zeitalter bei der Einführung API-basierter Architekturen und Geschäftsmodelle.
Thilo Frotscher – freiberuflicher Softwarearchitekt und Experte für Enterprise Java, APIs und Systemintegration.

Michael Hofmann: MVPs sind für mich das Mittel der Wahl. Daran kann man sehr schnell erkennen, wo die Probleme liegen. Dabei stellen sich technologische und organisationale Schwächen sehr schnell heraus. So lange das oberste Management dahinter steht, kann man auch einfacher auf Probleme in der Organisation eingehen.

Die technologischen Probleme sind mit den passenden Systemen dabei in der Regel einfacher in den Griff zu bekommen. Erst mit einem erfolgreichen MVP kann man aufzeigen, dass der neue Weg funktionieren kann. Das schafft Vertrauen bei den Mitarbeitern. Ohne dieses Vertrauen wird der Widerstand zu groß und das API-Projekt scheitert.

Christoph Wiechmann: Wie immer kommt es natürlich darauf an. Aber prinzipiell halte ich einen MVP-Ansatz für sinnvoll. Dieser sollte allerdings wirklich das Minimum definieren, was im ersten Schritt notwendig ist, und nicht schon zehn goldene Henkel, die das Projekt in Verzug bringen. Auf dieser Basis holt man sich das erste Feedback von Service-Providern & Consumern.

Thilo Frotscher: Die Technik zur Entwicklung von APIs ist überwiegend schon ausgereift. Natürlich gibt es einzelne Werkzeuge, die noch verbessert werden müssten. Hierzu zählen beispielsweise die diversen Generatoren im Umfeld von Swagger bzw. OpenAPI. Im Großen und Ganzen kann man aber mit den vorhandenen Technologien qualitativ hochwertige APIs entwickeln. Die auftretenden Schwierigkeiten sind eher im Entwicklungsprozess begründet. Es ist zwar richtig, dass sich APIs im Handumdrehen erstellen lassen. Leider verführt dieser Umstand aber auch dazu, sich im Vorfeld keine ausreichenden Gedanken darüber zu machen, wie eine gut verständliche und benutzbare API aussehen sollte.

Auch im Management vieler Unternehmen herrscht leider oft die Einstellung vor, neue APIs müssten extrem schnell fertig sein. Unter entsprechendem Zeitdruck wird dann gearbeitet. Stattdessen ist es jedoch wichtig sich ausreichend Zeit zu nehmen, um über so wichtige Themen wie API Design, Widerstandsfähigkeit und vor allem auch Sicherheit nachzudenken. Für Unternehmen oder Teams, die noch recht wenig Erfahrung mit der Entwicklung und Bereitstellung von APIs haben, empfiehlt es sich daher, einen Experten zu Rate zu ziehen, der wichtige Hinweise geben und vor den gängigen Fallen warnen kann.

APIs implementieren: Worauf kommt es an?

JAXenter: Was sollte ich bei der Implementierung einer API beachten?

Beim Design einer APIsollte man sich nicht von der Technologie treiben lassen.

Arne Limburg: Das Vorgehen, erst einmal klein anzufangen, um Erfahrung zu sammeln, ist auf jeden Fall ein Vorgehen, das sich bewährt hat. Dennoch sollte man sich beim Design einer API nicht von der Technologie treiben lassen. Es geht ja nicht primär darum, wie ich den Server schnell realisieren kann, sondern darum, eine API so aufzubauen, dass viele unbekannte Clients sie leicht nutzen können und gerne nutzen. Mein Ansatz ist deshalb immer der sogenannte Contract-First-Ansatz, wobei der Name etwas irreführend ist, weil er nicht das Ziel widerspiegelt. Eigentlich müsste man den Ansatz Client-First nennen. Gute APIs sind in der Regel die, bei denen das Design mit der Überlegung ausgeführt wurde: Was benötigt der Client?

Thilo Frotscher: Hier gibt es diverse Aspekte zu bedenken. Neben dem Thema Sicherheit sollte aus meiner Sicht vor allem die Widerstandsfähigkeit im Auge behalten werden. Beim Einsatz von APIs entstehen sehr häufig Verkettungen von HTTP-Anfragen. Es muss daher sichergestellt werden, dass Fehler, Blockaden oder Timeouts keinen Dominoeffekt erzeugen. Stattdessen werden Strategien benötigt, wie mit Retrys, Fail-Fast-Verhalten oder Default-Werten solchen Herausforderungen begegnet werden kann.

Lesen Sie auch: RESTful APIs richtig gemacht – Anleitung für bessere REST-Schnittstellen

Ein anderes Thema betrifft das Testen von APIs. Hier lautet meine Empfehlung, immer so produktionsnah wie möglich zu testen und damit zum frühestmöglichen Zeitpunkt zu beginnen. Gegebenenfalls können auch Kunden oder Clients bereits während der Entwicklungszeit eingebunden werden, so dass diese realitätsnahe Last und Datenvolumen für die Testumgebungen der API produzieren. Dies hilft im Übrigen auch dabei, Schwächen im API Design frühzeitig aufzuspüren. Wenn Kunden nachfragen, wie die neue API eigentlich funktionieren soll, dann ist sie offensichtlich nicht verständlich genau entworfen oder dokumentiert. Ebenso fällt so frühzeitig auf, wenn einer API noch bestimmte Funktionalität fehlt, die für Clients sehr sinnvoll wäre.

Tom Hombergs: Ich habe gute Erfahrungen mit dem Ansatz gemacht, klein anzufangen und auf dem Weg zu lernen. Bei der Einführung von APIs sollte man sich zuerst zwei möglichst kleine Schnittstellenpartner aussuchen, oder diese aus den Legacy-Systemen herausbrechen. So kann man Fehler machen, die nicht gleich ein großes Projektbudget kosten und aus ihnen lernen, sowohl technisch als auch organisatorisch. Das heißt natürlich nicht, dass man sich nicht schon Gedanken im Vorfeld machen darf, was ja leider hin und wieder als „nicht agil“ verschrien wird.

Die API-Themen der Experten

 JAXenter: Tom, deine Session auf der APIcon heißt „Contracts can be fun.“ Dabei stellst du Consumer-Driven Contracts mit Spring Boot Services in Verbindung mit einem Angular UI vor. Was leisten Consumer-Driven Contracts hier – welche Vorteile ergeben sich dadurch?

Tom Hombergs: Contracts erlauben es, Integrationstests zwischen API-Consumer und API-Provider auf die Ebene von Komponententests zu schieben. Die Tests des Consumers und des Providers laufen unabhängig voneinander, ohne dass der jeweils andere Schnittstellenpartner verfügbar sein muss. Das erleichtert die Ausführung der Tests enorm, denn wir müssen nicht für jeden Integrationstest eine lauffähige Umgebung mit beiden Schnittstellenpartnern zur Verfügung stellen. Wenn die Contracts „Consumer-Driven“ sind, ist zusätzlich sichergestellt, dass der Contract auch den Anforderungen des Konsumenten genügt und nicht eine API gebaut wird, die am Ende keiner braucht.

JAXenter: Christoph, deine Session auf der APIcon heißt „Das Zusammenspiel von Identity- und API-Management-Lösungen.“ Dabei gehst du auf die Integration der APIs mit einem Identity-Management-System ein, das externe und interne Identitäten validiert. Wie genau kann das funktionieren?

Christoph Wiechmann: Eine API-Management-Lösung soll in erster Linie API-Requests von verschiedenen konsumierenden Applikationen steuern und absichern. Das Zusammenspiel passiert auf Basis von Standard-Access-Tokens, wie JWT oder OAuth/Open-ID-Connect. Diese werden vom IDP an konsumierende Applikationen im Namen des Benutzers ausgestellt und müssen vom API-Management-System zur Runtime validiert werden. Die Validierung erfolgt entweder unter Mithilfe des IDPs oder bei Self-Contained-Token eigenständig. Soweit, so gut.

Der Punkt ist aber wieder der Self-Service auf der API-Management-Lösung. Oft sollen diese IDPs OAuth Token als JWT oder als Opak-Token ausgegeben, aber es wird nicht bedacht, dass sich dahinter Application-Credentials verbergen, welche aber im Sinne von Self-Service auf dem API-Developer-Portal erzeugt und verwaltet werden. Damit also ein IDP solche Access-Tokens überhaupt ausstellen kann, muss sich das im Self-Service betriebene API-Management-System mit dem IDP synchronisieren. Dieser Aspekt wird oft unterschätzt.

JAXenter: Was ist die Kernbotschaft deiner Session, die jeder mit nach Hause nehmen sollte?

Christoph Wiechmann: Die Einführung eines dezidierten Identity-Management Providers ist durchaus sinnvoll, da API-Management und Identity-Management aus der Architektur-Sicht nicht zusammen gehören. Trennt man diese Themen, ergeben sich daraus flexible Möglichkeiten, um z.B. verschiedene IDPs für z.B. Social-Login für End-Kunden oder Federated Login für Partner anzubieten, wenn man sich nicht auf einen IDP festlegt.

Aber beide Lösungen, gerade bei der Verwendung von OAuth-Access-Tokens, sind eng miteinander verbunden, wenn man eine API-Management-Plattform mit Self-Service etablieren möchte, und hier möchte ich gerne meine Erfahrung in diesem Bereich teilen.

JAXenter: Michael, dein Talk auf der APIcon heißt „API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen.“ Kannst du vielleicht einmal an einem Beispiel aufzeigen, welche Veränderungen die API Ecomony bei den Financial Services mit sich bringt?

Der Kern eines API-Projektes ist im Grunde der Change an sich.

Michael Hofmann: Die Banken unterliegen einem starken Wandel, der z.B. zu vermehrtem Filial-Sterben führt. Somit ist der Druck zur Digitalisierung und zu APIs sehr hoch.

Auf der anderen Seite sind die Systeme, die bisher für das Kerngeschäft entwickelt wurden, nicht sehr gut für APIs geeignet: Bisherige Nutzer dieser Kernsysteme waren in der Regel Bank-Mitarbeiter, die mit hohem fachlichen Wissen und voller Rechte-Struktur das System bedient haben. Jetzt kommen API-Konsumenten mit möglicherweise weniger Banken-Know-How und begrenzten Rechten als Anwender neu hinzu.

Die Erfahrung zeigt, dass nachträgliche Integration von neuen Rechte-Strukturen in ein über Jahre gewachsenes System sehr aufwändig ist. Außerdem ist es nicht immer ganz so leicht, komplexe Fachlichkeit einfach darzustellen und mit verständlichen APIs zu versehen.

JAXenter: Was ist die Kernbotschaft eurer Session?

Michael Hofmann: Ein API-Projekt sollte auf keinen Fall unterschätzt werden. Die Auswirkungen sind weitreichend. Leider belegen einige gescheiterte API-Projekte diese Aussagen schon. Der Kern eines API-Projektes ist im Grunde der Change an sich.

JAXenter: Vielen Dank für Eure Antworten!

Lesen Sie auch Teil 1 unseres API-Checks:

APIs programmieren: 5 Experten verraten Tipps & Tricks

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: