Seite 2: API-Abstraktion

Inhaltsverzeichnis

API-Abstraktion soll Abhilfe schaffen

Da das größte Problem in den Detailunterschieden liegt, selbst bei ähnlichen Diensten, scheint es naheliegend, ähnliche Dienste auf ein gemeinsames Interface zu abstrahieren. Auch ohne Zutun der Dienste kann man so einen Quasistandard schaffen. Je mehr ähnliche Funktionen die Services anbieten, desto mehr lässt sich abstrahieren. Das hat einige Vorteile.

Entwickler müssen sich nicht mehr in jede einzelne Dokumentation einlesen, sondern können sich auf ein Interface konzentrieren. Die Dienste, die das gemeinsame Interface implementieren, können im Code uniform behandelt werden, was ihn kürzer, prägnanter und weniger fehleranfällig macht.

Auch ist es einfacher, einen Dienst gegen einen anderen auszutauschen, falls der aktuell verwendete an Attraktivität verlieren sollte. Ein Nachteil ist zweifellos, dass Funktionen, über die nur ein spezieller Dienst verfügt, nicht abstrahiert werden können. Wird eine solche verwendet, gehen alle Vorteile der uniformen Behandlung und einfachen Austauschbarkeit verloren. Für Nutzer, die ausschließlich Standardfunktionen nutzen, zum Beispiel Upload und Download bei Cloud-Storage-Anbietern, kann die in der Abstraktion enthaltene Funktionalität jedoch oft ausreichen.

Es gibt mehrere Anbieter solch abstrahierter Integrationen, die sich grob in zwei Arten aufteilen lassen: IPaaS Middleware und abstrahierende SDKs.

Integration Platform as a Service oder abstrahierende SDKs

Kommerzielle Anbieter wie Kloudless und Cloud-Elements setzen darauf, eine Middleware bereitzustellen, oft unter dem Namen Integration Platform as a Service (IPaaS), die eine uniforme, abstrahierte Schnittstelle zu den Diensten bietet. Wie die Services selbst setzt eine solche IPaaS auf eine HTTP-Schnittstelle und SDKs für diverse Plattformen, um die Schnittstelle einfacher zugreifbar zu machen.

Ein klarer Vorteil ist, dass Entwickler auf beliebigen Plattformen die Abstraktion nutzen können, denn selbst wenn kein SDK für die eigene Plattform existiert, kann man immer noch direkt mit der HTTP-Schnittstelle interagieren. Leider hat der IPaaS-Ansatz auch einige Nachteile. Zuerst einmal stellt die Middleware einen alleinigen Ausfallpunkt dar. Sind die Server des Anbieters unerreichbar, funktioniert auch keine Integration mehr. Des Weiteren fließen alle Daten zwischen dem Dienst und der eigenen Anwendung über den Server des IPaaS-Anbieters, was besonders bei Cloud-Storage-Diensten unnötigen Datenverkehr und damit einhergehend Kosten verursacht, die an Kunden weitergegeben werden. Nicht zuletzt muss der IPaaS-Anbieter die Daten unverschlüsselt verarbeiten können, wie sonst würde man die vorher erwähnten Geburtsdaten normalisieren. Das stellt ein Problem aus Datenschutzsicht dar, besonders wenn die Server des Anbieters nicht in Deutschland stehen.

Ein alternativer Ansatz zu IPaaS stellen abstrahierende SDKs dar. Sie sind nicht als Middleware auf einem eigenen Server gehostet, sondern direkt als Bibliothek in die Anwendung integriert. Damit sind sie zumindest vonseiten der Hardware nicht anfällig für Ausfälle. Daten lassen sich mit HTTPS verschlüsseln, bevor sie das Gerät verlassen, und es findet kein Umweg statt. Es gibt eine Reihe an Produkten, die diesen Ansatz gehen, zum Beispiel die beiden Open-Source-Projekte Spring Social (für Java-Anwendungen) und HybridAuth (für PHP-Entwickler), aber auch das kommerzielle Produkt CloudRail mit abstrahierenden SDKs für Android, Java, Node.js, Swift und Objective-C. Die meisten fokussieren auf einen bestimmten Aspekt der API-Integration, andere wie das erwähnte CloudRail-Angebot haben etliche weitere Features im Angebot.

	Cloud Elements	CloudRail	HybridAuth	Kloudless	Spring Social
Technologie	Middleware	P2P/SDK	P2P/SDK	Middleware	P2P/SDK
Plattformen	Alle über API	Android, Java, Node.js, Objective-C, Swift	PHP	Alle über API	Java
Kommerziell	Ja	Ja	Nein	Ja	Nein
API-Kategorien	20	6	1	3 + 2 in Beta	1
API-Update-Prozess	Ja	Ja	Nein	Ja	Nein