erst für Partner oder gleich komplett öffentlich. Das funktioniert recht einfach, da sich öffentliche und private APIs inhaltlich sowie meist auch technisch nicht unterscheiden. Es liegen jedoch einige Unterschiede bei der Bereitstellung des APIs vor. Private Schnittstellen müssen sicherer verschlüsselt und deren Nutzung authentifiziert werden. Öffentliche APIs hingegen benötigen eine bessere Dokumentation und mehr Vorsicht bei der Wartung. Sollte man die Veröffentlichungsart des API verändern wollen, muss man beachten, dass sich damit auch die Prioritäten ändern, worauf man im Umfeld der Bereitstellung des API besonders Wert legen sollte.
Weitere Informationen zur privaten und öffentlichen API finden sich in Kapitel 2.2.1 sowie 2.2.2.
1.4Mögliche API-Technologien und -Spezifikationen
Nun stellt sich die Frage, wie genau eine Umsetzung oder Implementierung von APIs aussieht.
Es gibt mittlerweile eine Vielzahl von Paradigmen, Spezifikationen, Frameworks und Technologien, um ein API zu gestalten und zu implementieren. Um eine grobe Einordnung der Vielfalt zu bekommen, lohnt sich ein Blick zurück auf die Geschichte von APIs.
1.4.1Geschichte der Remote Execution
Schon seit der Entdeckung des Prinzips, ein Netzwerk durch die Verbindung zweier oder mehrerer Computer zu erzeugen, gibt es einen großen Bedarf daran, die Kommunikation dieser Maschinen zu optimieren. Die ersten Betriebssysteme Unix, Linux und Windows verfügten bereits über interne Protokolle für die verteilte Kommunikation. Doch die Herausforderung lag darin, ein generelles Framework für Entwickler zur Verfügung zu stellen.
Die 1990er- bis 2000er-Jahre
Als in den 1990ern TCP/IP zum Standard für Netzwerkkommunikation wurde, verschob sich der Fokus auf plattformübergreifende Interaktion. Eine Maschine konnte unabhängig vom Betriebssystem auf einer anderen Maschine eine Aktion initiieren.
Die COBRA-Bibliothek mit Protokollen und Algorithmen, Microsofts Distributed-Component-Object-Model-(DCOM-) Komponente oder die Java Remote Method Invocation (Java RMI) sowie andere Konzepte und Frameworks konnten als entwicklerfreundliche Abstraktionsschicht über der Kern-Netzwerk-Infrastruktur verwendet werden. Diese ersten Versuche, technologieunabhängige Kommunikation für maximale Reichweite in einem Cross-Plattform-Netzwerk zu entwickeln, war ein wichtiger Schritt in Richtung der heutigen Client/Server-Architektur.
Anfang der 2000er erfolgte dann die erste Evolution des World Wide Web, wie wir es heute kennen. HTTP etablierte sich dabei vom De-facto-Standard zum offiziellen Standard für die Netzwerkkommunikation. Vor allem mit der Kombination von HTTP und XML hatten Entwickler auf einmal ein selbstbeschreibendes, sprachen- und plattformunabhängiges Framework für die Kommunikation zur Verfügung.
Die Standardisierung dieses Frameworks erfolgte unter dem Namen Simple Object Access Protocol, kurz SOAP. Das ist eine Messaging-Protokoll-Spezifikation für den Austausch von strukturierten Informationen über das HTTP in einem Netzwerk aus verbundenen Webservices. Die Informationsstruktur wird dabei durch die Web Service Definition Language (WSDL) definiert, einem spezifischen XML-Format. Nun hatten Entwickler endlich Interoperabilität über alle Plattformen und Runtimes hinweg.
Das Web 2.0
Als nächster Schritt erfolgte die Entwicklung des Web hin zum sogenannten programmable Web oder auch Web 2.0. Es schoben sich statt einfacher, statischer Webseiten immer mehr Webanwendungen mit komplizierterer Architektur ins Internet. Die Interaktion des Nutzers mit der eigenen Webseite war der neue Fokus. Um diese Interaktionsmöglichkeiten zu bieten, war mehr Kommunikation zwischen Clients und Servern nötig. Die Schnittstellen, über die kommuniziert wurde, gewannen entsprechend deutlich an Bedeutung.
Im Vergleich mit der durch SOAP sehr restriktiven Netzwerkkommunikation über WSDL-XML und HTTP kam mit dieser größeren Bedeutung von APIs der Wunsch nach einem freieren Standard auf. Schon in der Webentwicklung wurden JavaScript und der Datenbeschreibungsstandard JavaScript Object Notation (kurz JSON) aufgrund der Freiheit und Flexibilität, die diese Technologien boten, immer beliebter. Der Wunsch lag nahe, diese Vorteile auch auf APIs auszudehnen. Als Resultat löste JSON letztendlich XML als Kommunikationsformat über HTTP ab.
Die Kombination von JSON und HTTP führten zu verschiedenen Interpretationen der Dissertation Architectural Styles and the Design of Network-based Software Architectures [21] des Netzwerkarchitektur-Pioniers Roy Fielding aus dem Jahre 2000. Diese werden heute generell als REST APIs zusammengefasst.
SOAP wurde seitdem nur noch für große Unternehmen verwendet, deren Systeme auf diesen Restriktionen basieren. Für moderne Neuentwicklungen wurde hingegen REST bevorzugt.
Heute und in Zukunft
Heutzutage, man könnte sagen »nach der Web-2.0-Revolution«, warten schon wieder neue Herausforderungen. Während im Web 2.0 Client-Server-Kommunikation und Webapplikationen der Hauptfokus waren, ist heute Microservices das Buzzword schlechthin. Aus dem Architekturstil, Applikationen immer verteilter zu entwickeln, folgt natürlich auch ein Anstieg der Kommunikation zwischen den Applikationen oder kleineren, eigenständigen Einzelteilen einer einzigen.
Auch das nächste große Buzzword ist nicht weit entfernt: das Internet of Things. Der Trend, immer mehr Alltagsgegenstände um eine Rechnerfunktionalität zu erweitern und miteinander zu verbinden, wird auch in Zukunft dafür sorgen, dass Schnittstellen zur Kommunikation zwischen verteilten Applikationen an Bedeutung gewinnen.
Da HTTP entwickelt wurde, um die Cross-Plattform-Kommunikation des Internets zu optimieren, muss die Frage gestellt werden, ob es sich hierbei immer noch um den optimalen Weg der Kommunikation innerhalb unserer verteilten Systeme handelt. Die erneut relevante Suche nach der Verbesserung dieser Kommunikation kann wieder zu neuen Innovationen führen.
Auch künftig werden die diversen Interpretationen von REST wohl die am weitesten verbreitete API-Art im Netz sein. Aber große Firmen und kleinere Communitys arbeiten schon an und mit neuen potenziellen Standards. Die Breite an Alternativen der Technologien und Konzepte war jedoch noch nie so groß. Von Googles gRPC, das das Grundkonzept von SOAP wiederbelebt, über die vom Ember.js-Erfinder und Open-Source-Pionier Yehuda Katz entwickelte JSON:API-Spezifikation bis hin zu Facebooks GraphQL – es halten viele neue Namen Einzug in die API-Welt.
Daher folgt auf den nächsten Seiten eine Übersicht einiger dieser Möglichkeiten der technologischen Realisierung von APIs.
1.4.2RESTful HTTP
REST steht für Representational State Transfer [21]. Es handelt sich dabei nicht um eine konkrete Technologie und keinen Standard, sondern vielmehr um einen Architekturstil oder ein Programmierparadigma, das 2000 von Roy Fielding in seiner Dissertation mit dem Titel Architectural Styles and the Design of Network-based Software Architectures konzipiert wurde.
REST ist ein Konzept, in dem Daten als Ressourcen gesehen werden. Diese können über eine eindeutige Adresse – eine URI – identifiziert werden und
