in viele private Smartphones hält. Das Spielprinzip hinter dem von Niantic entwickelten Mobile Game Ingress [35] ist spätestens seit dem Hype um Pokemon Go im Jahr 2016 [36] bekannt: mit dem Smartphone auf einer echten Karte der Umgebung und mit einer Augmented-Reality-Funktion der Kamera bestimmte Spielziele erfüllen. Öffentliche APIs ermutigen Entwickler, mit dem angebotenen Service ganz neue Wege zu beschreiten. Es findet auch hier eine Erweiterung der Geschäftsfelder und somit eventuell der Einnahmequellen des Anbieters statt.
1.3API: Die Definition
Was genau veröffentlicht ein API-Anbieter? Was integriert ein API-Konsument in seine eigenen Systeme? Was sind eigentlich API-Anbieter, API-Konsumenten, und was unterscheidet sie? Um diese Fragen zu beantworten, bedarf es klarer Definitionen von APIs und deren Akteuren.
1.3.1API-Vertrag
Wie bereits erwähnt, sind APIs wie Steckdosen: eine Abstraktion eines bestimmten Service, mit dem sich verschiedene Konsumenten in einer genau festgelegten Art verbinden können. Außer in einer Smarthome-Umgebung sind die Konsumenten eines API jedoch selten Toaster, sondern andere Programme, die die Funktionen des API nutzen oder integrieren möchten.
Martin Reddy verfasste 2011 eine kurze, allgemeine Definition von APIs [46]. Laut Reddy bieten APIs eine Abstraktion für ein Problem und spezifizieren, wie Benutzer mithilfe von Softwarekomponenten, die eine Lösung des Problems implementieren, interagieren sollen. Reddy spricht also davon, dass ein API aus mindestens zwei Teilen besteht: zum einen einer Abstraktion, die hilft, ein genaues Problem zu lösen, zum anderen die Spezifikation, wie mit ihr zu interagieren ist. 2014 ging Joshua Bloch auf Basis dieser Definition noch etwas tiefer ins Detail:
»Ein API spezifiziert die Operationen sowie Ein- und Ausgaben einer Softwarekomponente. Ihr Hauptzweck besteht darin, eine Menge an Funktionen unabhängig von ihrer Implementierung zu definieren, sodass diese Implementierung variieren kann, ohne die Benutzer der Softwarekomponente zu beeinträchtigen.« Joshua Bloch [9]
Bloch sieht somit ebenfalls sowohl eine Abstraktion von Funktionen als auch die genaue Spezifikation der Interaktion mit ihr als Teile des API, legt jedoch noch besonderen Wert auf die Trennung von Implementierung und der eigentlichen Schnittstelle.
Daniel Jacobson, Greg Brail und Dan Woods ziehen ähnliche Schlüsse und erarbeiten in ihrem Werk APIs – A Strategy Guide [37] folgende, ausführliche Definition für APIs:
API-Definition von Daniel Jacobson, Greg Brail und Dan Woods
Ein API ist ein Weg für zwei Computer, miteinander über ein Netzwerk (überwiegend das Internet) mit einer gemeinsamen Sprache, die beide verstehen, zu kommunizieren. APIs haben bestimmte Eigenschaften:
Der API-Anbieter beschreibt exakt, welche Funktionalität das API anbietet.
Der API-Anbieter beschreibt, wann die Funktionalität verfügbar ist und wann sie möglicherweise inkompatibel verändert wird.
Der API-Anbieter kann zusätzliche technische Beschränkungen des API skizzieren, beispielsweise Zugriffsraten und -grenzen, die kontrollieren, wie oft eine spezifische Anwendung, oder ein Endnutzer es innerhalb einer Stunde, eines Tags oder eines Monats benutzen darf.
Der API-Anbieter kann zusätzliche rechtliche oder geschäftliche Beschränkungen zur Benutzung des API skizzieren, beispielsweise markenschutzrechtliche Einschränkungen oder Arten der Benutzung.
Entwickler akzeptieren, das API so zu nutzen, wie es vom API-Anbieter beschrieben ist, und benutzen nur die Teile, die er beschrieben hat, nach den Regeln, die von ihm für die Nutzung festgelegt wurden.
Diese Auflistung an Rechten und Pflichten von API-Anbietern und konsumierenden Entwicklern sichert die Funktionsfähigkeit der Schnittstelle und wird deshalb auch seiner Form entsprechend API-Vertrag genannt. Dabei handelt es sich nicht etwa um ein festgelegtes Schriftstück, sondern um einen Begriff für die Erwartungshaltung des Entwicklers sowie das Versprechen des API-Anbieters über das dokumentierte Verhalten des API.
Bricht der API-Anbieter ein Verhaltensmuster des API, indem er zum Beispiel eine bestimmte Objektrepräsentation ändert, bricht er damit den API-Vertrag und stört meist auch die Funktionalität der gegen das API entwickelten Applikationen.
1.3.2Die Akteure eines API
Mit dem API-Anbieter und konsumierenden Entwicklern wurden bereits zwei Akteure bei der Verwendung eines API genannt. Es gibt in diesem Kontext also unterschiedliche Rollen.
Der API-Anbieter ist zumeist – aber nicht immer – auch der Besitzer des Service. Der Service wäre im bekannten Steckdosen-Beispiel der Strom und sein Besitzer daher der Stromanbieter. API-Anbieter wäre derjenige, der die Steckdose bereitstellt – also der Hauseigentümer. Mit dem Google-Maps-API wäre bei einem anderen Beispiel Google sowohl der Besitzer des Service – also dem Kartendienst – als auch der API-Anbieter.
Der Entwickler ist sozusagen der Gegenpart zum API-Anbieter, also der API-Konsument. Dieser entwickelt Applikationen mithilfe der Daten und Funktionen des API. Er verwendet direkt die Schnittstelle, ist somit der primäre Konsument.
Die Applikationen des Entwicklers werden letztendlich einem Endnutzer zur Verfügung gestellt, der Interesse an den Daten und Funktionen des API hat, jedoch nur indirekt über die Applikationen mit diesen Daten und Funktionen interagiert. Endnutzer sind also die sekundären Konsumenten und meist die eigentliche Motivation für die Entwicklung einer Schnittstelle.
Mehr Informationen zu den Akteuren im Umfeld einer API finden sich in Kapitel 2.1.
1.3.3Release-Arten von APIs
Der API-Anbieter hat volle Kontrolle darüber, wer sein API benutzen darf und wer nicht. Laut Daniel Jacobson, Greg Brail und Dan Woods [37] kann man von zwei verschiedenen Arten von APIs ausgehen: privat und öffentlich.
Öffentliche APIs sind für alle Entwickler nahezu ohne Einschränkungen und vertragliche Vereinbarungen mit dem API-Anbieter über ein offenes Netzwerk frei verfügbar. Hierzu zählen die großen und bekannten APIs, etwa von Twitter [58] oder Facebook [16].
Private APIs stellen laut dem CEO von Runscope, John Sheehan, den größten Teil der API-Welt [11]. Öffentliche APIs seien dabei höchstens die Spitze des Eisbergs, während Unternehmen heute sicher achtmal mehr private, als öffentliche APIs entwickeln. Das Konzept des privaten API muss dabei jedoch noch unterschieden werden zwischen internen und Partner-APIs.
Interne APIs befinden sich meist in abgeschlossenen Netzwerken und sind lediglich für die unternehmenseigenen Entwickler verfügbar. Partner-APIs dahingegen lassen auch zuvor vertraglich geregelte Zugriffe von (externen) Partnerentwicklern zu. Durch die geringere Zahl von Konsumenten können private oder nur für Partner veröffentlichte APIs besser an deren Wünsche und Bedürfnisse angepasst werden.
Die meisten Unternehmen beginnen mit der Entwicklung
