Wenn ein Onlineshop eine Kreditkartenzahlung abwickelt, ohne selbst eine Zahlungsinfrastruktur zu betreiben, steckt meist die Schnittstelle von Stripe oder PayPal dahinter. Wenn eine App eine Karte mit Wegbeschreibung anzeigt, ist es in den meisten Fällen die Programmierschnittstelle von Google Maps. Eine API, kurz für Application Programming Interface, legt fest, welche Funktionen und Daten ein System nach außen zur Verfügung stellt und nach welchen Regeln ein anderes Programm darauf zugreifen darf. Sie erspart Entwicklern, Dinge wie Kartenmaterial oder Zahlungsabwicklung selbst zu bauen, und lässt sie stattdessen auf bereits bestehende, geprüfte Systeme zugreifen.
Vom entfernten Funktionsaufruf zum REST-Standard
Frühe Web-APIs liefen häufig über SOAP, ein Protokoll mit sperrigem XML-Format und festen Regelwerken. Der Informatiker Roy Fielding beschrieb im Jahr 2000 in seiner Doktorarbeit einen Gegenentwurf: REST, kurz für Representational State Transfer. REST nutzt die ohnehin vorhandenen Methoden des Webs, also GET, POST, PUT und DELETE, und tauscht Daten meist im schlankeren JSON-Format aus, einer Textform, die sowohl Menschen als auch Maschinen leicht lesen können, statt im komplexeren XML. Weil REST auf bestehenden Web-Standards aufbaut statt ein eigenes Regelwerk zu erfinden, hat es sich in den vergangenen zwei Jahrzehnten zum verbreitetsten Muster für öffentliche APIs entwickelt.
GraphQL als Alternative für komplexe Datenabfragen
Facebook stieß mit REST an eine praktische Grenze, als das Unternehmen seine mobile App aus fest programmierten Webseiten in eine native Anwendung umbaute. Damit eine einzige Bildschirmansicht alle nötigen Daten bekam, mussten mit REST oft mehrere Endpunkte nacheinander abgefragt werden, was auf langsamen Mobilfunkverbindungen spürbar Zeit kostete. Ein Team um Dan Schafer, Lee Byron und Nick Schrock entwickelte deshalb ab 2012 eine neue Abfragesprache und brachte sie im selben Jahr für den Facebook-Newsfeed in den produktiven Einsatz. Facebook veröffentlichte die Technik 2015 als Open-Source-Projekt unter dem Namen GraphQL und übergab sie 2018 an die GraphQL Foundation, die bei der Linux Foundation angesiedelt ist. Der Unterschied zu REST in der Praxis: Ein Client fragt bei GraphQL in einer einzigen Anfrage genau die Felder ab, die er tatsächlich braucht, statt mehrere feste Endpunkte der Reihe nach abzurufen.
OpenAPI und Swagger als gemeinsame Sprache
Damit zwei Entwicklerteams, die nie miteinander gesprochen haben, dieselbe Schnittstelle richtig benutzen, braucht es eine einheitliche Beschreibung. Der Entwickler Tony Tam legte dafür 2010 bei der Wörterbuch-Firma Wordnik den Grundstein mit dem Projekt Swagger. Der Softwarehersteller SmartBear kaufte die Spezifikation im März 2015 von Wordniks Mutterfirma, und im November desselben Jahres gründeten SmartBear und weitere Unternehmen wie Google, Microsoft, IBM und PayPal gemeinsam die OpenAPI Initiative unter dem Dach der Linux Foundation. Die bestehende Swagger-2.0-Spezifikation wurde dabei zur Grundlage von OpenAPI. Eine API, die nach diesem Standard dokumentiert ist, lässt sich von fremden Entwicklern direkt in einem Tool öffnen, das automatisch passenden Beispielcode erzeugt, ganz ohne den Quellcode der Gegenseite zu kennen.
Wie Unternehmen Schnittstellen im Alltag einsetzen
Neben Zahlungsanbietern wie Stripe und PayPal und Kartendiensten wie Google Maps nutzen Unternehmen APIs auch, um interne Systeme zu verbinden, etwa eine Warenwirtschaft mit dem eigenen Onlineshop. Häufig kommt dabei ein Webhook zum Einsatz, das Gegenstück zur normalen API-Abfrage: Statt dass ein System immer wieder nachfragt, ob sich etwas geändert hat, meldet sich das andere System von selbst, sobald ein Ereignis eintritt, etwa eine neue Bestellung. Das spart Anfragen und hält Systeme in Echtzeit statt nur in festen Abständen aktuell.
Sicherheitsrisiken, die mit offenen Schnittstellen wachsen
Jede zusätzliche Schnittstelle ist auch ein zusätzlicher Angriffspunkt. Die Sicherheitsorganisation OWASP führt seit 2019 eine eigene Rangliste der häufigsten API-Schwachstellen, und an der Spitze steht dort unverändert die sogenannte Broken Object Level Authorization: Eine API prüft zwar, ob jemand eingeloggt ist, aber nicht, ob der angefragte Datensatz tatsächlich dieser Person gehört. Wer in einer solchen Anfrage lediglich die ID-Nummer austauscht, kann dadurch fremde Daten einsehen. Laut OWASP steckt dieser Fehler hinter rund 40 Prozent aller untersuchten API-Angriffe, weshalb Zugriffsprüfungen bei jeder neuen Schnittstelle von Anfang an mitgeplant werden müssen und nicht nachträglich ergänzt werden sollten.
Warum sich die Wahl der Schnittstelle langfristig auszahlt
Eine gut dokumentierte, sauber abgesicherte API entscheidet oft darüber, wie schnell sich ein Unternehmen mit Partnern, Zahlungsdienstleistern oder eigenen künftigen Anwendungen verbinden kann. Wer beim Aufbau eigener Schnittstellen auf offene Standards wie REST oder GraphQL setzt und sie nach OpenAPI dokumentiert, spart nicht nur der eigenen Entwicklungsabteilung Zeit, sondern jedem externen Team, das die Schnittstelle später nutzt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen REST und GraphQL?
REST nutzt die Standardmethoden des Webs wie GET, POST, PUT und DELETE und tauscht Daten meist im JSON-Format aus, wobei ein Client häufig mehrere Endpunkte nacheinander abfragen muss. GraphQL, das Facebook ab 2012 entwickelte und 2015 als Open Source veröffentlichte, lässt einen Client in einer einzigen Anfrage genau die Felder abrufen, die er tatsächlich braucht. Facebook stieß bei der Umstellung seiner mobilen App auf REST an eine praktische Grenze, weil mehrere Abfragen auf langsamen Mobilfunkverbindungen spürbar Zeit kosteten.
Wofür dient die OpenAPI-Spezifikation?
OpenAPI ist eine einheitliche Beschreibungssprache, mit der zwei Entwicklerteams, die nie miteinander gesprochen haben, dieselbe Schnittstelle richtig benutzen können. Sie geht auf das Projekt Swagger zurück, das der Entwickler Tony Tam 2010 bei Wordnik startete, und wurde 2015 von SmartBear zusammen mit Unternehmen wie Google, Microsoft, IBM und PayPal zur OpenAPI Initiative unter dem Dach der Linux Foundation weiterentwickelt. Eine nach diesem Standard dokumentierte API lässt sich von fremden Entwicklern direkt in einem Tool öffnen, das automatisch passenden Beispielcode erzeugt.
Was ist ein Webhook und wie unterscheidet er sich von einer normalen API-Abfrage?
Bei einer normalen API-Abfrage muss ein System selbst immer wieder nachfragen, ob sich etwas geändert hat. Ein Webhook kehrt das Prinzip um. Das andere System meldet sich von selbst, sobald ein Ereignis eintritt, etwa eine neue Bestellung, was Anfragen spart und Systeme in Echtzeit statt nur in festen Abständen aktuell hält.
Was ist Broken Object Level Authorization und warum gilt sie als größtes API-Sicherheitsrisiko?
Eine API mit dieser Schwachstelle prüft zwar, ob jemand eingeloggt ist, aber nicht, ob der angefragte Datensatz tatsächlich dieser Person gehört. Wer in einer Anfrage lediglich die ID-Nummer austauscht, kann dadurch fremde Daten einsehen. Laut OWASP steckt dieser Fehler hinter rund 40 Prozent aller untersuchten API-Angriffe, weshalb Zugriffsprüfungen von Anfang an mitgeplant werden sollten statt nachträglich ergänzt zu werden.