Tatsache ist: Es gibt eine generell hohe Motivation für den Einsatz von Web-APIs. Nicht nur, dass damit wertvolle Ressourcen geschont werden (keine eigene Softwareentwicklung notwendig) und sich bestehende Produkte oder Dienstleistungen schnell und unkompliziert erweitern lassen. Web-APIs ermöglichen darüber hinaus die Interoperabilität zwischen externen und internen Systemen und eröffnen Unternehmen dadurch Chancen für neue Geschäftsmodelle und Partnerschaften mit anderen Firmen.
Man denke beispielsweise an die Kooperation zwischen einer Krankenversicherung und einem medizinischen Institut für Infektionskrankheiten. Die vom Institut zur Verfügung gestellten Informationen könnten dem Versicherer helfen, Gefahrensituationen schneller zu erkennen, zu bewerten und gemeinsam mit Health-Anbietern frühzeitig wirkungsvolle Therapien für den Versicherten zu entwickeln. Auch das könnte man über einen entsprechenden Web-API-Dienst umsetzen.
REST ist nicht die einzige Option
80 Prozent aller Web-API, die heute zum Einsatz kommen, basieren auf der REST-Architektur (siehe Glossar). Dabei handelt es sich strenggenommen nicht um ein Protokoll, sondern um einen Ansatz, wie man mittels HTTP bestimmte Einschränkungen (Constraints) sowie die Interaktion zwischen virtuellen Maschinen, Systemen und Anwendungen beschreiben kann. Das Interessante dabei ist, dass HTTP nicht für APIs entwickelt wurde, sondern für Webseiten. Warum also ist REST so stark verbreitet?
Zum einen ist diese Architektur einfach zu verstehen und lässt sich viel schneller umsetzen als andere, beispielsweise das komplexe SOAP-Protokoll, das von 2000 bis 2010 besonders stark verbreitet war und noch heute im Einsatz ist. SOAP wurde ausschließlich für die Interaktion zwischen Servern und nicht für die Client-Server-Kommunikation entwickelt. Zudem ist SOAP sehr „mächtig“ und verlangt schon ein tiefes Programmier-Know-how. Im Gegensatz dazu ist REST eher „schlank“ gehalten und für jeden, der einigermaßen HTTP versteht, leicht zu begreifen bzw. in der Praxis umzusetzen.
Trotzdem besitzt die REST-Architektur einige Einschränkungen. Da es sich hier nicht um einen weltweit gültigen Standard handelt, ermöglicht sie eine freie Auslegung in der Anwendung und Entwicklung – frei nach dem Motto: Jeder kann machen, wie er denkt, dass es richtig ist. Entsprechend hoch ist die Vielzahl an unterschiedlichen Umsetzungen.
Genau da liegt das Problem: Die Anwendung von REST-API mag zwar einfach sein. Doch die „saubere“ Implementierung von REST-APIs – gutes Design, detaillierte und verständliche Dokumentation, stringentes Management – stellt eine große, organisatorische Herausforderung dar. Zudem sind CRUD-Operationen für Datenbanken und statische Datenspeicher bei REST eher beschränkt; und für die Umsetzung von Anforderungen wie IoT, KI und Bots, die andere Arten von APIs benötigen, ist die REST-Architektur nicht ideal.
Eine weitere Herausforderung bei REST besteht darin, dass man immer die komplette Ressource anfordern muss – auch, wenn man nur eine einzige, kleine Eigenschaft (Attribut) benötigt. Dieses „Overfetching“ ist in manchen Fällen ein gravierender Nachteil von REST-APIs.
Natürlich existieren mit gRPC, RSocket, W3C SPARQL, GraphQL, JSON:API, OASIS Odata ernstzunehmende Alternativen. So spiegelt beispielsweise das von Google entwickelte Protokoll gRPC gewissermaßen die moderne Welt der API-Kommunikation wider. Das auch außerhalb von Google zum Einsatz kommende Protokoll ist ein leichtgewichtigerer Ansatz als das mächtige SOAP und sehr effizient bei der Verarbeitung von Daten. Vor allem in der Kommunikation zwischen Systemen innerhalb eines Unternehmens stößt man in der Praxis auf gRPC. Dabei wird hauptsächlich über einen Binärtransport kommuniziert (mehr zu gRPC siehe Glossar unten). Kurz: Bei der Entwicklung einer API-Strategie sollte man nicht von vornherein ausschließlich auf REST setzen, sondern auch Alternativen prüfen.
Inzwischen haben viele Unternehmen und Organisationen sogenannte Guidelines für den Umgang und den Einsatz von APIs veröffentlicht. Diese Leitfäden beschreiben zum Beispiel, wie die APIs gesichert sein sollten, welche Namenskonventionen gelten, welche HTTP-Headers unterstützt werden, wie Fehlermeldungen auszusehen haben und vieles mehr. Sie sind sowohl für die Programmierer im jeweiligen Unternehmen als auch für externe Anwender gedacht, um regelkonform API-Services zu entwickeln und zu nutzen.
Wer beispielsweise die Suchplattform von Zalando in sein Unternehmensportal integrieren will, muss die API-Guideline des Online-Versandhändlers genau kennen und für die Umsetzung berücksichtigen. Da viele Firmen ihre Regelwerke öffentlich zur Verfügung stellen, ist es für Unternehmen, die gerade begonnen haben, sich mit dem Thema API zu beschäftigen, eine wichtige Quelle. Man könnte auch sagen: Sie profitieren von diesem unternehmensübergreifenden Know-how-Transfer insofern, als dass sie von den Erfahrungen der „alten Hasen“ lernen und sich von erfolgreich durchgeführten API-Projekten inspirieren lassen können. Eine aktuelle Übersicht findet man unter http://apistylebook.com/design/guidelines/.
Fest steht: APIs als geschäftskritische Faktoren bedürfen eines strikten Managements (Governance). Noch nie war das technologische „Ökosystem“ so reichhaltig wie heute. Schnell kann man hier den Überblick verlieren. Daher ist eine klare API-Strategie ungemein wichtig. Dabei sollte man im Hinterkopf behalten, dass REST nicht alle Probleme löst. Es gibt auch andere gute Architekturen bzw. Ansätze. Entscheidend sind letzten Endes die spezifischen Unternehmensanforderungen (Was will man durch die Etablierung einer API-Economy erreichen?) und eine ausgiebige Analyse der vorhandenen Struktur. Zu empfehlen ist in diesem Zusammenhang, bei der Nutzung von externen API-Services nicht nur auf einen Anbieter zu setzen bzw. den Einfluss eines externen Dienstleisters auf die eigene Infrastruktur möglichst gering zu halten.
Firmen, die sich ausschließlich auf einen API-Dienstleister konzentrieren, laufen Gefahr, durch plötzliche Marktveränderungen von einem Tag auf den anderen keinen Zugriff mehr auf die Services zu bekommen; beispielsweise dann, wenn Anbieter und Abnehmer auf Grund der Ähnlichkeit ihrer Geschäftsfelder plötzlich zu Wettbewerbern werden oder wenn es Rechtsstreitigkeiten gibt.
Noch gut in Erinnerung ist der Fall PeopleLinx (jetzt Frontline Selling). Gegründet von ehemaligen Mitarbeitern der Businessplattform LinkedIn, wurde dem Unternehmen von LinkedIn „über Nacht“ der Zugriff auf dessen API-Dienste verweigert. Der Vorwurf: PeopleLinx habe auf LinkedIn unerlaubt Daten abgegriffen und diese anderen Unternehmen zur Verfügung gestellt. Damit habe man gegen vertragliche Bestimmungen über die Verwendung der zur Verfügung gestellten APIs verstoßen, so LinkedIn. Plötzlich stand PeopleLinx ohne die dringend benötigten API-Services da.
Übrigens – Verletzungen des Datenschutzes sind nicht selten der Grund dafür, dass Kooperationen innerhalb einer API-Economy in die Brüche gehen. Vielen noch gut in Erinnerung ist der Cambridge-Analytica-Skandal. Das von der britischen SCL Group gegründete Analyse-Unternehmen hatte bei Facebook unerlaubt Daten abgegriffen und diese für gezielte Marketingbotschaften zugunsten des Brexit in Großbritannien genutzt. Möglich war das, weil es Schwachstellen in den von Facebook zur Verfügung gestellten APIs gab.