API

Eine API, Application Programming Interface, ist eine maschinenlesbare Schnittstelle zu einer Software-Komponente, die unter Verwendung von Standard-Technologien über ein Netzwerk aufgerufen werden kann. Sie dient dem Austausch und der einfachen Weiterverarbeitung von Daten.

 

Bei einer API geht es weniger um die Einführung einer neuen Technologie, als um eine andere Art mit Schnittstellen umzugehen: die Bereitstellung von Self-Service, 1:n, wiederverwendbaren Schnittstellen. APIs sind aus Nutzersicht geschrieben. Der Anwender muss keine spezifische Software oder Wissen über interne Prozesse oder Systeme haben. Moderne APIs sind auf einfache Nutzung statt auf einfache Erstellung ausgerichtet.

Bei der Einführung einer API sind neben der reinen Entwicklung auch API Governance, Cyber Security, die Messung der API-Performance, die Betreuung der App-Entwickler und ggf. Bezahlmodelle zu berücksichtigen. 90% aller APIs sind intern genutzt. Meist werden so erst interne Daten strukturiert, dann anderen Geschäftsbereichen verfügbar gemacht und schließlich Kunden, Partnern, oder der Allgemeinheit.

Interne oder private API werden intern oder restriktiv mit ausgewählten Partnern oder Kunden genutzt. Externe oder public/open API sind allgemein verfügbar.

Man unterscheidet auch verwaltete API mit einer klaren Definition und Zielgruppe von nicht-verwalteten API mit definierter Schnittstelle aber ohne weiteres Monitoring. Letztere kommen z.B. bei Sensoren wie Fitbit zum Einsatz.

 

Zur Standardisierung der Struktur einer API werden Protokolle wie SOAP und REST verwendet.

SOAP (ursprünglich Simple Object Access Protocol, heute eingetragener Markenname in den USA) ist ein industrieller Standard des W3C und unterstützt somit auch alle andere W3C-Standards wie WS-Policy oder WS-Security. Bei SOAP handelt es sich um ein Netzwerkprotokoll, meist werden HTTP oder TCP verwendet, möglich sind auch SMTP oder JMS. Als Datenformat wird meist XML verwendet, es sind aber auch andere Formate möglich.

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, welchem ein lokaler Name zugewiesen werden muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf http://www.w3.org/2003/05/soap-envelope. Kind dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem können Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zur Transaktionsidentifizierung, untergebracht werden. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Zur Semantik applikations-spezifischer Daten macht SOAP keinerlei Vorschriften, es stellt lediglich ein Framework zu deren Übertragung zur Verfügung.

REST steht für Representational State Transfer und ist der inzwischen deutlich häufiger verwendete Standard. REST ist ein Architekturstil, Kernidee ist das Konzept der Ressource. Ort und Name der Ressource werden in der URL abgebildet, z.B. http://example.com/orders. REST funktioniert unabhängig von jedweden Protokollen, üblicherweise wird aber HTTP verwendet. Bei REST wird stets über einen einheitlichen Satz von Standardmethoden auf eine Ressource zugegriffen, bei HTTP über die Methoden GET (lesen), POST (erstellen), PUT (ändern) und DELETE (löschen).

 

Als Datenformate bei APIs kommen meist JSON oder XML zum Einsatz.

JSON, JavaScript Object Notation, ist ein einfaches Format, in dem Objekte mit zwei Teilen beschrieben werden: keys und values. Keys sind Attribute eines Objektes, wie Bearbeitungsstatus oder Belag einer Pizza. Values sind die Ausprägungen dieser Attribute, also 'versandt' oder 'Pilze', 'Salami'. Dabei lässt sich auch ein Objekt als value einbetten.

XML, Extensible Markup Language, dient der Darstellung hierarchisch strukturierter Daten im Format einer Textdatei und ist plattform- und implementationsunabhängig. Hier ist jeweils ein Anfangs-Node erforderlich, der den key angibt, gefolgt von den values und abgeschlossen von einem End-Node.

 

Für die Autorisierung hat sich das Framework OAuth2 etabliert. Hier gibt es vier unterschiedliche Abläufe: die sicherste Methode ist der Authorization Code Grant. Wenn die Client-App keinen Server hat, gibt es die Abwandlung des Implicit Grant. Für die reine Server-to-Server-Kommunikation gibt es die Vorgehensweise des Client Credential und beim Password Grant oder Resource Owner Password gibt der User sein Password für den Server in der Client-App ein. Eine Vorgehensweise, die man normalerweise vermeiden möchte.

Für die Authentifizierung sind bekannte Standards FacebookConnect, Google FriendConnect oder der OpenId-Standard. Statt des Aufbaus eines eigenen Userpools erfolgt die Authentifizierung hier über sogenannte Identity Provider, genannt Single Sign-On. OpenId ist ein Standard, den unterschiedlichste Anbieter verwenden und der eine Spezialisierung innerhalb des OAuth2-Frameworks darstellt.

 

Eine Aktion des Servers, wen sich dort Daten ändern, ist in der Architektur von APIs schwierig. Es gibt die Möglichkeit des Polling, einer regelmäßigen Anfrage des Clients beim Server, des Long Polling, wenn der Server erst bei einer Änderung der Daten auf die Anfrage des Clients antwortet, oder des Webhooks. Hier wird der Client zum Server und kann somit Requests empfangen. Dafür stellt er dem Server eine callback URL zur Verfügung, an die der Server Updates sendet.

PDF Download