SOAP wurde seitdem nur noch für große Unternehmen verwendet, deren Systeme auf diesen Restriktionen basieren. Für moderne Neuentwicklungen wurde hingegen REST bevorzugt.
Heute und in Zukunft
Heutzutage, man könnte sagen »nach der Web-2.0-Revolution«, warten schon wieder neue Herausforderungen. Während im Web 2.0 Client-Server-Kommunikation und Webapplikationen der Hauptfokus waren, ist heute Microservices das Buzzword schlechthin. Aus dem Architekturstil, Applikationen immer verteilter zu entwickeln, folgt natürlich auch ein Anstieg der Kommunikation zwischen den Applikationen oder kleineren, eigenständigen Einzelteilen einer einzigen.
Auch das nächste große Buzzword ist nicht weit entfernt: das Internet of Things. Der Trend, immer mehr Alltagsgegenstände um eine Rechnerfunktionalität zu erweitern und miteinander zu verbinden, wird auch in Zukunft dafür sorgen, dass Schnittstellen zur Kommunikation zwischen verteilten Applikationen an Bedeutung gewinnen.
Da HTTP entwickelt wurde, um die Cross-Plattform-Kommunikation des Internets zu optimieren, muss die Frage gestellt werden, ob es sich hierbei immer noch um den optimalen Weg der Kommunikation innerhalb unserer verteilten Systeme handelt. Die erneut relevante Suche nach der Verbesserung dieser Kommunikation kann wieder zu neuen Innovationen führen.
Auch künftig werden die diversen Interpretationen von REST wohl die am weitesten verbreitete API-Art im Netz sein. Aber große Firmen und kleinere Communitys arbeiten schon an und mit neuen potenziellen Standards. Die Breite an Alternativen der Technologien und Konzepte war jedoch noch nie so groß. Von Googles gRPC, das das Grundkonzept von SOAP wiederbelebt, über die vom Ember.js-Erfinder und Open-Source-Pionier Yehuda Katz entwickelte JSON:API-Spezifikation bis hin zu Facebooks GraphQL – es halten viele neue Namen Einzug in die API-Welt.
Daher folgt auf den nächsten Seiten eine Übersicht einiger dieser Möglichkeiten der technologischen Realisierung von APIs.
1.4.2RESTful HTTP
REST steht für Representational State Transfer [21]. Es handelt sich dabei nicht um eine konkrete Technologie und keinen Standard, sondern vielmehr um einen Architekturstil oder ein Programmierparadigma, das 2000 von Roy Fielding in seiner Dissertation mit dem Titel Architectural Styles and the Design of Network-based Software Architectures konzipiert wurde.
REST ist ein Konzept, in dem Daten als Ressourcen gesehen werden. Diese können über eine eindeutige Adresse – eine URI – identifiziert werden und sind in einem spezifischen Format – nach Fieldings ursprünglicher Vision XML – repräsentiert. Eine Ressource kann sowohl ein einzelnes Objekt als auch eine Sammlung – also Collection – von Objekten sein (siehe Abbildung 1–2).
Abb. 1–2 Ressourcen, Repräsentation und URI im Zusammenhang
Kommunizieren kann der Client mit den Ressourcen bei einer RESTful API über HTTP und dessen Methoden. Diese sind POST, GET, PUT sowie DELETE und bilden die CRUD-Operationen (Create, Read, Update, Delete). Die Kommunikation findet dabei in einem Request/Response-Muster statt. Der Client stellt über die HTTP-Methoden entsprechende Requests an die gewünschte Ressource des API, und der Server antwortet mit einer Response: bei einem lesenden Zugriff beispielsweise mit der Repräsentation dieser Ressource im Body der Response.
Ein Request auf solch ein RESTful API über die Konsole – mit einem sogenannten cURL-Befehl – würde beispielhaft dann wie folgt aussehen:
$ curl -X GET "https://api.shop.com/user/5"
Listing 1–1 REST GET Request
Hier fordert der Client einen lesenden Zugriff auf den User mit der ID 5. Auf diesen Request würde er nun vom Server folgende Response erhalten:
< HTTP/1.1 200 OK
< Status: 200 OK
< Content-Length: 1782
< Content-Type: application/json
<
{"id":"5","username":"luke"}
Listing 1–2 REST GET Response
Der HTTP-Statuscode zeigt an, dass der Request erfolgreich abgearbeitet wurde. Die Rückgabe enthält mit dem JSON-Objekt am Ende die Repräsentation der Ressource des Users mit der id = 5. Ähnlich funktioniert auch ein schreibender Request des Clients:
$ curl -X PUT "https://api.shop.com/user/5" -d
'{"id":"5","username":"leia"}'
Listing 1–3 REST PUT
Bei diesem Beispiel handelt es sich um einen Request zum Überschreiben des Nutzers mit der id = 5. Die neue Objektrepräsentation wird im Request mitgeliefert und ersetzt serverseitig die bisherige Repräsentation der Ressource.
Ein weiterer Punkt in Fieldings Definition von REST – oder eher noch: sein Hauptaugenmerk bei der Architektur – war das sogenannte Hypermedia as the Engine of Application State oder auch HATEOS. Hierbei sollte der Zugriff des Clients lediglich auf einen initialen Endpunkt des Service beschränkt werden. Dieser hält neben der eigenen Repräsentation auch Verbindungen zu anderen Ressourcen bereit. Ein Client kann also alle möglichen Endpunkte dynamisch entdecken – ähnlich dem Durchklicken verschiedener Links auf einer Webseite.
HATEOS wird jedoch selten strikt durchgesetzt, weshalb nicht unbedingt Fieldings Vision von REST, sondern eher eine pragmatischere Interpretation heute als REST bezeichnet wird und weitläufig verbreitet ist.
1.4.3JSON:API
JSON:API ist eine JSON-basierte API-Spezifikation mit dem Ziel, API-Calls effizienter zu gestalten. Genau wie REST ist es eine Kombination aus HTTP und JSON sowie einer Definition von Regeln und Standards für die Kommunikation. JSON:API hat einfache Ressourcen, die über einen Call gegen den definierten Endpunkt des Service abgerufen werden können.
GET /articles HTTP/1.1
Accept: application/vnd.api+json
Listing 1–4 JSON API Get Request
Als Response liefert der Server ein JSON-Dokument. Das hat eine definierte, erwartbare Struktur. So hält es ein Relationship-Objekt, das sowohl Informationen über die Beziehung der Ressource zu anderen Ressourcen hält, als auch weitere, einfache Informationen zur Beziehung. Ruft man den Link innerhalb der angegebenen Relation auf, erhält man die Repräsentation der in Beziehung zu ihr stehenden Ressource – ähnlich dem HATEOS-Prinzip bei REST.
// ...
{
"type": "articles",
"id": "1",
"attributes": {
"title": "The Force for Beginners"
},
"relationships": {
"author": {
"links": {