GraphQL. Dominik Kress
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 eines privaten API und veröffentlichen dann nach und nach Teile dessen – entweder erst für Partner oder gleich komplett öffentlich. Das funktioniert recht einfach, da sich öffentliche und private APIs inhaltlich sowie meist auch technisch nicht unterscheiden. Es liegen jedoch einige Unterschiede bei der Bereitstellung des APIs vor. Private Schnittstellen müssen sicherer verschlüsselt und deren Nutzung authentifiziert werden. Öffentliche APIs hingegen benötigen eine bessere Dokumentation und mehr Vorsicht bei der Wartung. Sollte man die Veröffentlichungsart des API verändern wollen, muss man beachten, dass sich damit auch die Prioritäten ändern, worauf man im Umfeld der Bereitstellung des API besonders Wert legen sollte.
Weitere Informationen zur privaten und öffentlichen API finden sich in Kapitel 2.2.1 sowie 2.2.2.
1.4Mögliche API-Technologien und -Spezifikationen
Nun stellt sich die Frage, wie genau eine Umsetzung oder Implementierung von APIs aussieht.
Es gibt mittlerweile eine Vielzahl von Paradigmen, Spezifikationen, Frameworks und Technologien, um ein API zu gestalten und zu implementieren. Um eine grobe Einordnung der Vielfalt zu bekommen, lohnt sich ein Blick zurück auf die Geschichte von APIs.
1.4.1Geschichte der Remote Execution
Schon seit der Entdeckung des Prinzips, ein Netzwerk durch die Verbindung zweier oder mehrerer Computer zu erzeugen, gibt es einen großen Bedarf daran, die Kommunikation dieser Maschinen zu optimieren. Die ersten Betriebssysteme Unix, Linux und Windows verfügten bereits über interne Protokolle für die verteilte Kommunikation. Doch die Herausforderung lag darin, ein generelles Framework für Entwickler zur Verfügung zu stellen.
Die 1990er- bis 2000er-Jahre
Als in den 1990ern TCP/IP zum Standard für Netzwerkkommunikation wurde, verschob sich der Fokus auf plattformübergreifende Interaktion. Eine Maschine konnte unabhängig vom Betriebssystem auf einer anderen Maschine eine Aktion initiieren.
Die COBRA-Bibliothek mit Protokollen und Algorithmen, Microsofts Distributed-Component-Object-Model-(DCOM-) Komponente oder die Java Remote Method Invocation (Java RMI) sowie andere Konzepte und Frameworks konnten als entwicklerfreundliche Abstraktionsschicht über der Kern-Netzwerk-Infrastruktur verwendet werden. Diese ersten Versuche, technologieunabhängige Kommunikation für maximale Reichweite in einem Cross-Plattform-Netzwerk zu entwickeln, war ein wichtiger Schritt in Richtung der heutigen Client/Server-Architektur.
Anfang der 2000er erfolgte dann die erste Evolution des World Wide Web, wie wir es heute kennen. HTTP etablierte sich dabei vom De-facto-Standard zum offiziellen Standard für die Netzwerkkommunikation. Vor allem mit der Kombination von HTTP und XML hatten Entwickler auf einmal ein selbstbeschreibendes, sprachen- und plattformunabhängiges Framework für die Kommunikation zur Verfügung.
Die Standardisierung dieses Frameworks erfolgte unter dem Namen Simple Object Access Protocol, kurz SOAP. Das ist eine Messaging-Protokoll-Spezifikation für den Austausch von strukturierten Informationen über das HTTP in einem Netzwerk aus verbundenen Webservices. Die Informationsstruktur wird dabei durch die Web Service Definition Language (WSDL) definiert, einem spezifischen XML-Format. Nun hatten Entwickler endlich Interoperabilität über alle Plattformen und Runtimes hinweg.
Das Web 2.0
Als nächster Schritt erfolgte die Entwicklung des Web hin zum sogenannten programmable Web oder auch Web 2.0. Es schoben sich statt einfacher, statischer Webseiten immer mehr Webanwendungen mit komplizierterer Architektur ins Internet. Die Interaktion des Nutzers mit der eigenen Webseite war der neue Fokus. Um diese Interaktionsmöglichkeiten zu bieten, war mehr Kommunikation zwischen Clients und Servern nötig. Die Schnittstellen, über die kommuniziert wurde, gewannen entsprechend deutlich an Bedeutung.
Im Vergleich mit der durch SOAP sehr restriktiven Netzwerkkommunikation über WSDL-XML und HTTP kam mit dieser größeren Bedeutung von APIs der Wunsch nach einem freieren Standard auf. Schon in der Webentwicklung wurden JavaScript und der Datenbeschreibungsstandard JavaScript Object Notation (kurz JSON) aufgrund der Freiheit und Flexibilität, die diese Technologien boten, immer beliebter. Der Wunsch lag nahe, diese Vorteile auch auf APIs auszudehnen. Als Resultat löste JSON letztendlich XML als Kommunikationsformat über HTTP ab.
Die