REST API (RESTful API)

Wie RESTful APIs funktionieren

Eine RESTful API zerlegt eine Transaktion in eine Reihe kleiner Module. Jedes Modul befasst sich mit einem zugrunde liegenden Teil der Transaktion. Diese Modularität bietet Entwicklern eine große Flexibilität, aber es kann für Entwickler eine Herausforderung sein, ihre REST API von Grund auf zu entwerfen. Derzeit stellen mehrere Unternehmen Modelle zur Verfügung, die von Entwicklern verwendet werden können. Die Modelle von Amazon S3, Cloud Data Management Interface (CDMI) und OpenStack Swift sind die beliebtesten.

Eine RESTful API verwendet Befehle, um Ressourcen abzurufen. Der Zustand einer Ressource zu einem bestimmten Zeitpunkt wird als Ressourcendarstellung bezeichnet. Eine RESTful API verwendet bestehende HTTP-Methoden, die durch das RFC-2616-Protokoll definiert sind. Dazu gehören unter anderem:

• GET, um eine Ressource abzurufen;
• PUT, um den Zustand einer Ressource, die ein Objekt, eine Datei oder ein Block sein kann, zu ändern oder zu aktualisieren;
• POST, um diese Ressource zu erstellen, und
• DELETE, um sie zu entfernen.

Bei REST sind die vernetzten Komponenten eine Ressource, auf die der Benutzer zugreifen möchte, wie eine Blackbox, deren Implementierungsdetails unklar sind. Alle Aufrufe sind zustandslos; nichts kann vom RESTful-Dienst zwischen den Ausführungen gespeichert werden.

Zu den von der REST API unterstützten Datenformaten gehören:

• application/json
• application/xml
• application/x-wbe+xml
• application/x-www-form-urlencoded
• multipart/form-data

Da die Aufrufe zustandslos sind, ist REST in Cloud-Anwendungen nützlich. Zustandslose Komponenten können im Falle eines Fehlers beliebig neu bereitgestellt werden und sie können skaliert werden, um Laständerungen auszugleichen. Das liegt daran, dass jede Anfrage an eine beliebige Instanz einer Komponente gerichtet werden kann; es kann nichts gespeichert werden, was sich die nächste Transaktion merken müsste.

Das macht REST für den Einsatz im Web vorteilhaft. Das RESTful-Modell ist auch bei Cloud-Diensten hilfreich, da die Bindung an einen Dienst über eine API eine Frage der Kontrolle darüber ist, wie die URL entschlüsselt wird. Cloud Computing und Microservices führen dazu, dass das RESTful-API-Design in Zukunft die Regel ist.

RESTful-API-Design und -Architekturbeschränkungen

Das Design von RESTful APIs wurde von Dr. Roy Fielding in seiner Dissertation aus dem Jahr 2000 definiert. Um eine echte RESTful API zu sein, muss ein Webdienst die folgenden sechs REST-Architektureinschränkungen einhalten:

• Verwendung einer einheitlichen Schnittstelle. Ressourcen sollten durch eine einzige URL eindeutig identifizierbar sein, und nur durch die Verwendung der zugrunde liegenden Methoden des Netzwerkprotokolls, wie DELETE, PUT und GET mit HTTP, sollte es möglich sein, eine Ressource zu verändern.
• Client-/Server. Es sollte eine klare Abgrenzung zwischen Client und Server geben. Die Benutzeroberfläche und das Sammeln von Anfragen sind die Domäne des Clients. Datenzugriff, Workload-Management und Sicherheit sind die Domäne des Servers. Durch diese lose Kopplung von Client und Server können beide unabhängig voneinander entwickelt und verbessert werden.
• Zustandslose Operationen. Alle Client-Server-Operationen sollten zustandslos sein, und jede erforderliche Zustandsverwaltung sollte auf dem Client und nicht auf dem Server stattfinden.
• RESTful-Ressourcen-Caching. Alle Ressourcen sollten eine Zwischenspeicherung ermöglichen, es sei denn, es wird ausdrücklich darauf hingewiesen, dass eine Zwischenspeicherung nicht möglich ist.
• Mehrschichtiges System. REST ermöglicht eine Architektur, die aus mehreren Schichten von Servern besteht.
• Code auf Anfrage. Die meiste Zeit sendet ein Server statische Darstellungen von Ressourcen in Form von XML oder JSON zurück. Bei Bedarf können die Server jedoch auch ausführbaren Code an den Client senden.

REST-API-Herausforderungen

Neben den Einschränkungen in Bezug auf Design und Architektur gibt es bei REST APIs auch einige Herausforderungen. Einige Konzepte, die eine Herausforderung darstellen, sind:

• Konsistenz der Endpunkte – die Pfade der Endpunkte sollten konsistent sein, indem sie gemeinsamen Webstandards folgen, was schwierig zu handhaben sein kann.
• API-Versionierung – Endpunkt-URLs sollten nicht ungültig werden, wenn sie intern oder mit anderen Anwendungen verwendet werden.
• Lange Antwortzeiten und zu viele Daten – die Menge der zurückgegebenen Ressourcen kann mit der Zeit an Umfang zunehmen, was zu erhöhten Lade- und Antwortzeiten führt.
• Navigationspfade und Orte für Benutzereingaben – da REST URL-Pfade für Eingabeparameter verwendet, kann die Bestimmung von URL-Bereichen eine Herausforderung darstellen.
• Security – es gibt viele Aspekte, die man im Auge behalten muss, darunter die Verwendung von:
  • HTTPS;
  • Blockieren des Zugriffs von unbekannten IP-Adressen und Domänen;
  • Validierung von URLs;
  • Blockieren unerwartet großer Nutzdaten;
  • Protokollierung von Anfragen; und
  • Untersuchung von Fehlern.
• Authentifizierung – Verwenden Sie gängige Authentifizierungsmethoden wie die HTTP-Basisauthentifizierung (die eine base64-kodierte Zeichenfolge aus Benutzername und Passwort zulässt), API-Schlüssel, JSON-Web-Token und andere Zugriffstoken. OAuth0 eignet sich zum Beispiel gut für die Zugriffskontrolle.
• Anfragen und Daten – Anfragen können mehr Daten und Metadaten enthalten, als benötigt werden, oder es können mehrere Anfragen erforderlich sein, um alle Daten zu erhalten. APIs können an diese Gegebenheiten angepasst werden.
• API-Tests – die Einrichtung und Durchführung kann ein langwieriger Prozess sein. Jeder Teil des Prozesses kann entweder langwierig oder anspruchsvoll sein. Die Tests können auch über die Befehlszeile mit dem Dienstprogramm Curl durchgeführt werden. Zu den Teilen des Testprozesses, die schwierig sein können, gehören:
  • Ersteinrichtung
  • Schema-Updates
  • Test von Parameterkombinationen
  • Abfolge von API-Aufrufen
  • Validierung von Testparametern
  • Systemintegration
• Definieren Sie Fehlercodes und -meldungen.
  • Bei den Fehlercodes ist es gängige Praxis, Standard-HTTP-Fehlercodes zu verwenden. Diese werden von Kunden und Entwicklern häufiger erkannt.
  • Bei der Fehlerbehandlung gibt es neben dem Parsen des Textbereichs oder der Prüfung auf Fehler keine Möglichkeit zu unterscheiden, ob eine Antwort erfolgreich ist oder nicht.

REST versus SOAP

REST und Simple Object Access Protocol (SOAP) bieten unterschiedliche Methoden zum Aufrufen eines Webdienstes. REST ist ein Architekturstil, während SOAP ein Standard-Kommunikationsprotokoll für den XML-basierten Nachrichtenaustausch definiert. REST-Anwendungen können SOAP verwenden.

REST-basierte Webdienste sind zustandslos. Eine REST-Implementierung ist im Vergleich zu SOAP einfach, aber die Benutzer müssen den Kontext und den Inhalt, der weitergegeben wird, verstehen, da es kein Standard-Regelwerk zur Beschreibung der REST-Webdienstschnittstelle gibt. REST-Dienste sind nützlich für Geräte mit eingeschränktem Profil, wie zum Beispiel Mobiltelefone, und lassen sich leicht in bestehende Websites integrieren.

SOAP erfordert weniger speziell entwickelten Code, das heißt Low-Level-Infrastrukturcode, der die Hauptcodemodule miteinander verbindet, als das Design von REST-Diensten. Die Web Services Description Language (WSDL) beschreibt einen gemeinsamen Satz von Regeln zur Definition der Nachrichten, Bindungen, Operationen und des Standorts des Dienstes. SOAP-Webdienste sind für die asynchrone Verarbeitung und den Aufruf nützlich.

Geschichte der RESTful APIs

Vor der Einführung von REST verwendeten Entwickler SOAP, um APIs zu integrieren. Um einen Aufruf zu tätigen, schrieben die Entwickler von Hand ein XML-Dokument mit einem Remote Procedure Call (RPC) im Hauptteil. Anschließend gaben sie den Endpunkt an und sendet ihre SOAP-Hülle an den Endpunkt.

Im Jahr 2000 beschlossen Roy Fielding und eine Gruppe von Entwicklern, einen Standard zu schaffen, mit dem jeder Server mit jedem anderen Server kommunizieren kann. In seiner Dissertation an der University of California aus dem Jahr 2000 definierte er REST und die oben beschriebenen architektonischen Beschränkungen. Diese universellen Regeln erleichtern den Entwicklern die Integration von Software.

Salesforce war das erste Unternehmen, das im Jahr 2000 eine API als Teil seines as-a-Service-Pakets verkaufte. Allerdings waren nur wenige Entwickler in der Lage, die komplizierte XML API tatsächlich zu nutzen. Dann entwickelte eBay eine REST API, die den Markt auf jede Website ausdehnte, die auf ihre API zugreifen konnte. Dies erregte die Aufmerksamkeit eines anderen E-Commerce-Riesen, und Amazon kündigte seine API im Jahr 2002 an.

Flickr brachte im August 2004 seine eigene RESTful API auf den Markt, die es Bloggern ermöglichte, Bilder auf ihren Websites und in Social Media Feeds einzubetten. Facebook und Twitter veröffentlichten ihre APIs im Jahr 2006 und beugten sich dem Druck von Entwicklern, die die Websites auswerteten und "Frankenstein"-APIs erstellten. Als Amazon Web Services (AWS) 2006 zur Einführung der Cloud beitrug, konnten Entwickler mit der REST API von AWS innerhalb von Minuten auf Datenräume zugreifen, und die Nachfrage nach öffentlichen APIs stieg schnell an.

Seitdem haben Entwickler RESTful APIs für sich entdeckt und nutzen sie, um ihre Websites und Anwendungen um zusätzliche Funktionen zu erweitern.