API-Abstraktion zur Beschleunigung des Entwicklungsprozesses

Softwareentwickler müssen sich heute der Herausforderung stellen, unzählige externe APIs in ihre Anwendungen einzubinden, um dem Nutzer Mehrwert zu bieten. Da die APIs oft unterschiedlich sind, kann das zum echten Zeitfresser werden. API-Abstraktion verspricht hier Abhilfe, jedoch gibt es unterschiedliche Ansätze.

Know-how  –  0 Kommentare
API-Abstraktion zur Beschleunigung des Entwicklungsprozesses

Egal ob man mobile Anwendungen, Websites, Desktop-Programme oder Servercode schreibt, Entwickler müssen oft mehrere externe APIs anbinden. Die mobile Anwendung soll das Log-in mit einem von vielen sozialen Netzen ermöglichen, eine Website soll Buttons zum Liken und Kommentieren haben, Desktop-Programme sollen Daten bei einem Cloud-Storage-Anbieter sichern – am besten kann sich der Nutzer aussuchen bei welchem – und der Server sendet eine E-Mail nach erfolgreicher Registrierung eines neuen Nutzers. All das erfordert Zugriff auf APIs von Anbietern wie Facebook, Dropbox und SendGrid.

Apps benötigen immer mehr Integrationen über APIs (Abb. 1)

Die meisten Anbieter exponieren ihre Dienste über HTTP-Schnittstellen und stellen oft auch SDKs für verschiedene Plattformen bereit, welche die eigentliche HTTP-Kommunikation kapseln und hinter Funktionen verstecken. Doch bereits die Authentifizierung stellt Entwickler vor Hürden. Will man über die API auf den eigenen Account zugreifen, zum Beispiel bei SMS-Anbietern, reicht es meist, einen API-Schlüssel bei den Anfragen mitzugeben. Möchten Entwickler aber Zugriff auf die Daten des Nutzers bekommen, etwa bei Cloud-Storage-Anbietern, geschieht das meist über OAuth 1.0 und/oder OAuth 2.0.

OAuth 2.0 zeichnet sich im Vergleich zu seinem Vorgänger durch mehr Flexibilität und geringere Komplexität dank HTTPS statt aufwendigem Signierungsprozess aus. Beiden gemein ist, dass sie einer Anwendung erlauben, von ihren Nutzern Zugriff auf deren Daten zu bekommen, ohne dass diese Nutzername und Passwort an die Anwendung geben müssen. Stattdessen authentifiziert sich der Nutzer bei dem Dienst und autorisiert den Zugriff auf seine Daten, worauf der Dienst der Anwendung Zugriff erteilt.

Auch wenn OAuth 2.0 die Komplexität verringert und mittlerweile deutlich weiter verbreitet ist als OAuth 1.0, müssen Entwickler den veralteten Standard ebenfalls verstehen, da er auch auf Serverseite noch in verschiedenen Implementierungen anzutreffen ist. Zudem gibt es nach wie vor prominente Dienste wie Twitter, die auf OAuth 1.0 setzen.

Das verbreitetste Konzept zur Strukturierung solcher APIs ist ohne Zweifel REST (Representational State Transfer). Es gibt unter anderem vor, dass Ressourcen strukturiert über URIs (Uniform Resource Identifier) zugreifbar und eindeutig adressierbar sein sollen. Der Zugriff erfolgt üblicherweise über HTTP(S), wobei die Operation auf der Ressource über die HTTP-Methode (GET, POST, PUT, DELETE ...) spezifiziert wird.

Während sich viele APIs auf die Fahne schreiben, "RESTful" zu sein, scheint doch jeder eine leicht andere Vorstellung davon zu haben, wie das konkret aussieht – sicherlich auch, weil REST mehr Paradigma als detaillierter Standard ist. Das macht den Aufbau der APIs uneinheitlich.

Auch bei den Datenformaten gibt es Unterschiede: Hier sind zumeist JSON oder XML gesetzt, wobei JSON als lesbarer und kompakter gilt, während XML etwas "mächtiger" ist. Besonders in der Browserumgebung mit allgegenwärtigem JavaScript spielt JSON seine Stärke aus, lässt es sich doch direkt auf JavaScript-Objekte abbilden. XML hingegen erlaubt von Haus aus Referenzen, selbst zyklische, und beliebige Datentypen. Die Herausforderung für Entwickler ergibt sich, weil manche APIs JSON benutzen und andere XML. Seltener finden sich solche, die wahlweise beides anbieten.

Die eigentlichen Daten, die ein Dienst zurückgibt oder entgegennimmt, unterscheiden sich ebenfalls. Als einfaches Beispiel soll das Geburtsdatum eines Benutzers dienen. So gibt Facebook einen String im Format "MM/DD/YYYY" zurück beziehungsweise "YYYY" oder "MM/DD", wenn die Information nicht vollständig öffentlich ist.

Facebook nutzt ein anderes Format für Datum als andere Anbieter (Abb. 2).

Google+ verwendet "YYYY-MM-DD", und Microsoft Live liefert drei separate Zahlen für Tag, Monat und Jahr. Entwickler kommen also nicht darum herum, sich mit solchen Details auseinanderzusetzen und die Informationen auf das Format zu normalisieren, das sie intern verwenden.

Auch bei der Dokumentation der API bekleckert sich nicht jeder Dienst mit Ruhm. Es gibt Dienste, die sowohl die HTTP-Schnittstelle als auch die SDKs mit ausführlicher Dokumentation versehen, hilfreiche Beispiele inklusive, aber eben auch solche bei denen eine Hand voll Beispiele das Höchste der Gefühle ist und man oft nur durch Recherche oder Ausprobieren dahinter kommt, wie man bestimmte Informationen auslesen oder eingeben kann.

Nicht zuletzt ist zu beachten, dass die Kommunikation mit einer solchen API nicht immer ohne Fehler verläuft. Wenn Nutzer eine ungültige Eingabe machen, können Entwickler zwar abfangen, dass zum Beispiel eine E-Mail-Adresse ein String im korrekten Format ist, nicht aber ohne Weiteres, ob die Adresse wirklich existiert und sich eine E-Mail an diese tatsächlich ausliefern lässt. Es ist deshalb wichtig, die Fehlermeldungen des Servers erkennen und auf die Ausnahmezustände reagieren zu können. Auch hier zeigen sich APIs uneinheitlich. Oft hat der Fehler keine direkte oder nur eine unspezifische Entsprechung in einem HTTP-Statuscode, sodass er oft nur wenig hilfreich ist. Die Fehlerbeschreibung und der maschinenlesbare Code, die entweder im Body oder im Header gesendet werden, sind oft API-spezifisch.

Die genannten Probleme beziehen sich hauptsächlich auf die direkte Interaktion mit der HTTP-API, aber auch beim Benutzen der SDKs der Anbieter haben Entwickler mit den meisten der genannten Unterschiede zu kämpfen.