API-Design. Kai SpichaleЧитать онлайн книгу.
versioniert. Die Twitter-API v1, die 2006 online ging, wurde beispielsweise erst 2013 eingestellt. Zuvor gab es bereits eine neuere Version der API, sodass Entwickler ausreichend Zeit hatten, ihre Anwendungen umzustellen. Manche APIs leben sogar ewig. Denn aus der Java-Standardbibliothek wurden bisher keine Elemente entfernt, sondern nur als veraltet markiert.
Internet der Dinge
Das nächste große Kapitel der API-Geschichte trägt den Titel »Internet der Dinge« (Internet of Things – IoT). Hinter diesem Trend steckt die Idee, unterschiedlichste intelligente Geräte zu vernetzen, um Menschen bei ihren Tätigkeiten zu unterstützen. Das Spektrum dieser intelligenten Geräte reicht von Kühlschränken bis zu Autos. Mithilfe verschiedener APIs kann man auf die IoT-Einheiten zugreifen. Dies geschieht häufig drahtlos per Wi-Fi, BLE (Bluetooth Low Energy) oder NFC (Near Field Communication). Beispiele sind ThingSpeak, eine Open-Source-Lösung, mit der Entwickler unter Zuhilfenahme von Webtechnologien mit Geräten interagieren können, und OGC SensorThings API, ein Standard zum einheitlichen Zugriff auf IoT-Einheiten, Daten und Applikationen über das Web.
1.3API-Definition
Eine API kann man allgemein definieren als ein Programmteil, das von einem Softwaresystem anderen zur Anbindung zur Verfügung gestellt wird [Wikipedia 2016]. Diese Definition betont korrekterweise den Integrationszweck einer API. Eine API beschreibt aber auch die möglichen Interaktionen, mit denen sie verwendet werden kann. Deswegen gehört zu einer API eine detaillierte Dokumentation der Schnittstellenfunktionen mit ihren Parametern. Laut Martin Reddy [Reddy 2011] bietet eine API eine Abstraktion für ein Problem und spezifiziert, wie Benutzer mithilfe von Softwarekomponenten, die eine Lösung für das Problem implementieren, interagieren sollten.
Allgemeine API-Definition
Eine andere Definition, die wir auch für dieses Buch verwenden wollen, stammt von Joshua Bloch: »Eine API spezifiziert die Operationen sowie die Ein- und Ausgaben einer Softwarekomponente. Ihr Hauptzweck besteht darin, eine Menge an Funktionen unabhängig von ihrer Implementierung zu definieren, sodass die Implementierung variieren kann, ohne die Benutzer der Softwarekomponente zu beeinträchtigen« [Bloch 2014].
API-Typen in diesem Buch
Diese allgemeine Definition verdeutlicht, dass »API« nur der Oberbegriff für viele unterschiedliche API-Spielarten ist. Konkret unterscheidet dieses Buch zwischen Programmiersprachen-APIs und Remote-APIs:
Programmiersprachen-APIs werden beispielsweise von Bibliotheken angeboten und sind sprach- und plattformabhängig. Als Vertreter der Programmiersprachen-APIs behandelt das Buch objektorientierte Java-APIs.
Auf der Seite der Remote-APIs bietet das Buch RESTful HTTP, SOAP-Webservices und Messaging-APIs. Diese APIs sind durch Protokolle wie HTTP sprach- und plattformunabhängig. Diese Eigenschaften erfüllen ebenfalls SOAP-Webservices, die mit und ohne HTTP (z. B. über eine Message Queue) genutzt werden können. Messaging-APIs bieten asynchrone Kommunikation auf Protokollen wie AMQP (Advanced Message Queuing Protocol) oder MQTT (Message Queue Telemetry Transport). Darüber hinaus gibt es auch Remote Procedure Calls (RPCs) und dateibasierte APIs für Konfigurationen und asynchronen Informationsaustausch.
Abb. 1–1Es gibt verschiedene API-Typen. In diesem Buch werden objektorientierte Java-APIs, Web-APIs und Messaging-APIs behandelt.
Service Provider Interface
Auch Frameworks haben eine API, über die sie benutzt und erweitert werden können. Ein Service Provider Interface (SPI) ist eine API, die dazu bestimmt ist, von einem Benutzer erweitert oder implementiert zu werden. Auf diese Weise kann eine Applikation oder ein Framework Erweiterungspunkte bereitstellen. Generell ist für Programmiersprachen-APIs das Thema Vererbung wichtig.
API versus Protokoll
Häufig werden APIs und Protokolle im gleichen Kontext verwendet. Dennoch können und sollten die Begriffe voneinander getrennt werden.
Eine objektorientierte API kann ein Protokoll kapseln. Ein Beispiel dazu ist im Java-Umfeld RMI (Remote Method Invocation). Eine Implementierung dieser Java-API nutzt intern das Protokoll JRMP (Java Remote Method Protocol) für entfernte Aufrufe zwischen Objekten. Ein anderes Beispiel ist JMS (Java Messaging Service). Diese Java-API für Message Queues wird von einem JMS-Provider (z. B. ActiveMQ) mithilfe eines zugrunde liegenden Protokolls (z. B. AMQP) umgesetzt. Eine API-Implementierung kann demzufolge ein Protokoll kapseln bzw. es implementieren. Umgekehrt gilt das nicht: Ein Protokoll kann keine API kapseln oder implementieren.
HTTP ist ein Protokoll, das ist unstrittig, aber HTTP allein stellt noch keine API dar. Eine API kann man jedoch als eine Menge von HTTP-Requests und -Responses inklusive der Struktur der verwendenten Nachrichten definieren. Häufig spricht man in diesem Fall von einer Web-API oder allgemein von einer Remote-API.
Ein anderes anschauliches Beispiel sind WebSockets, weil hier Protokoll und API konsequent voneinander getrennt sind. Das Web-Socket-Protokoll ist in RFC 6455 [Fette & Melnikov 2011] standardisiert und spezifiziert u. a. das Öffnen und Schließen von Verbindungen mit Handshake. Die WebSocket-API [Hickson 2011] definiert u. a. ein WebSocket-Interface mit den Methoden send und close. Mithilfe der API können Webseiten das WebSocket-Protokoll für die Zwei-Wege-Kommunikation mit einem entfernten Host nutzen. Moderne Webbrowser exponieren die API und nutzen das Protokoll zur Kommunikation mit entfernten Servern, die das Protokoll möglicherweise hinter einer serverseitigen API anbinden.
1.4Vorteile einer API
In der zuvor betrachteten kurzen Geschichte der APIs wurden bereits einige Vorteile beschrieben. Ein wichtiger Vorteil, der sich durch die Trennung zwischen API und Implementierung ergibt, ist die Änderbarkeit oder Austauschbarkeit der Implementierung. Solange der Vertrag der API eingehalten wird, müssen Benutzer ihren Code nicht anpassen. Aus diesem Ansatz ergeben sich mehrere Vorteile:
Stabilität durch lose Kopplung
Angenommen Benutzer einer Softwarekomponente wären direkt von den Implementierungsdetails der Softwarekomponente abhängig, dann wäre der Code des Benutzers instabil, weil dieser schon bei kleinen Änderungen der Softwarekomponente angepasst werden müsste. Diese starke Kopplung zwischen einer Softwarekomponente und ihren Benutzern kann durch eine API minimiert werden. Falls beispielsweise ein Webservice seine Ein-Server-Lösung durch eine Lösung mit verteilter Architektur ersetzen muss, weil die Benutzeranzahl wächst und Performance-Probleme auftreten, sollte die Änderung keine Auswirkungen auf bestehende Benutzer haben, obwohl die neue Lösung auf einer völlig anderen Architektur basiert.
Portabilität
Beispielsweise kann ein in ANSI C geschriebenes Programm auf verschiedenen Computerarchitekturen und Betriebssystemen ausgeführt werden, sofern eine konforme C-Implementierung vorhanden ist. Als Beispiel könnte man auch die Java Runtime Environment (JRE) nennen, denn sie bietet für Java-Programme eine einheitliche API-Implementierung für verschiedene Betriebssysteme.
Komplexitätsreduktion durch Modularisierung
Eine API bietet eine geeignete Abstraktion und versteckt die Komplexität der Implementierung. Diese nicht notwendige Kenntnis des API-Benutzers über Implementierungsdetails folgt dem Geheimnisprinzip und hilft, die Komplexität großer Anwendungen zu beherrschen. Die Modularisierung hat wiederum Vorteile für Arbeitsteilung und Entwicklungskosten.
Softwarewiederverwendu ng und Integration
Eine