Was ist eine REST API?

APIs haben sich im modernen Computing als die gängigste Art und Weise für Programme und Geräte etabliert, um miteinander zu interagieren. Eine API ist ein Regelwerk, das beschreibt, wie sich ein Programm mit einem anderen verbinden und so mit diesem kommunizieren kann. Wie der Name schon sagt, überträgt eine REST API mit jeder Anfrage den Zustand der jeweiligen Transaktion, was Design-, Leistungs- und Ressourcenvorteile gegenüber anderen Ansätzen mit sich bringt. REST wurde über mehr als zwei Jahrzehnte entwickelt und ist heute ein besonders gängiger Ansatz für dienstbasierte und verteilte Architekturen.

Ein grundlegendes Konzept für REST APIs ist die Ressource. Eine Ressource ist ein Objekt mit einem Typ, zugehörigen Daten, Beziehungen zu anderen Ressourcen und einer Reihe von Methoden, die auf diesem arbeiten. Dies ähnelt stark der Idee von Objekten in der Programmierung, wobei jedoch nur wenige Standardmethoden definiert sind: HTTP GET, POST, PUT und DELETE. Ressourcen können entweder alleine vorhanden sein oder in Kollektionen zusammengefasst werden, die selbst wiederum Ressourcen sind.

Ein gebräuchliches Modell im modernen Computing – und ebenfalls grundlegend für REST APIs – ist das Client-Server-Modell, in dem ein Client, der eine Ressource benötigt, einen Server identifiziert, der diese Ressource bereitstellen kann, und mit diesem kommuniziert. Praktisch der gesamte Cloud-Traffic wird auf diese Weise geregelt, da dies maximale Flexibilität bietet, damit mehrere Clients auf mehrere Server zugreifen können. Das Prinzip ist auch für sogenannte „Serverless“-Architekturen geeignet, in denen ein Service Broker den Platz eines dem Client bekannten Servers einnimmt.

Die Entwicklung der REST-API-Architektur begann 1993, als Websites für den allgemeinen Gebrauch zugänglich wurden.

Die schnelle Ausbreitung des Internets führte zu konkurrierenden Vorschlägen für Erweiterungen des ursprünglichen HyperText Transfer Protocol (HTTP). Das World Wide Web Consortium (W3C) und die Internet Engineering Task Force (IETF) begannen, neue Versionen von HTTP, HTML (HyperText Transfer Language) und URI-Standards zu bewerten und zu formalisieren.

Nachdem er sechs Jahre an der HTTP- und URI-Standardisierung gearbeitet hatte, definierte der Forscher Roy Fielding im Jahr 2000 den REST-Standard und legte damit den Architekturstil fest, um künftige Entwicklungen von Internetprotokollen zu überprüfen und Erweiterungen zu identifizieren, die nicht zu den Verhaltens- und Leistungszielen des Internets passten.

Die REST-Konzepte haben sich in der Folge als ausgesprochen anpassungsfähig an die Weiterentwicklung des vernetzten Computing erwiesen. 2015 entwickelte die OpenAPI Initiative mit Unterstützung der Linux Foundation mit Mitgliedern wie Google, IBM, Microsoft und PayPal die OpenAPI Specification, die auf RESTful-Regeln basiert und maschinenlesbare Interface-Dateien zur Beschreibung, Produktion, Nutzung und Visualisierung von RESTful-Webdiensten veröffentlicht.

Anwendungen, die auf der Grundlage von OpenAPI-Interface-Dateien eingerichtet werden, können automatisch eine Dokumentation zu Methoden, Parametern und Modellen generieren. Neben einem Branchenfokus für standardisierte Header, Codes, Ressourcenbeschreibungen und zukünftige Innovationen liefert die OpenAPI Initiative auch Tools, Referenzmaterial und Best Practices. Diese sind besonders wichtig für die Erstellung, Überprüfung und ordnungsgemäße Verwendung von Authentifizierungs- und Datensicherheitsprozessen nach Art des RESTful-Konzepts, was der OpenAPI Initiative ein besonderes Anliegen ist.

1. Einheitliches Interface

Alle Anfragen an eine REST API müssen die Formatierungsregeln dieser API einhalten. Unabhängig davon, welcher Client die Anfrage stellt, muss dieser jede Information an der Stelle angeben, wo dies auch jeder andere Client tun würde. Dies gilt zum Beispiel für die URL (Uniform Resource Locator), die zur Identifizierung von Ressourcen via HTTP dient. Bei dieser handelt es sich um ein Beispiel eines Uniform Resource Identifier (URI), der auch breiter einsetzbar sein kann.

2. Trennung von Client und Server

REST APIs setzen voraus, dass Client- und Serveranwendungen voneinander vollkommen unabhängig sind. Der Client muss nur den vollständigen Namen der gewünschten Ressource in dem von der API zugelassenen virtuellen Raum kennen. Darüber hinaus ist das einzige, was Client und Server voneinander wissen, das, was über API-Transaktionen ausgetauscht wird.

3. Zustandslosigkeit

Jede Client-Anfrage muss alle nötigen Informationen für ihre Verarbeitung enthalten, und der Server muss nach Erhalt keinerlei Informationen über diese Anfrage speichern. Das REST-API-Design enthält kein Konzept einer Sitzung und der Server bleibt hinsichtlich jeglichen Clients zustandslos („stateless“).

4. Cachefähigkeit

Im Gegensatz zur Zustandslosigkeit des Servers für jeden Client sollten Ressourcen an einem oder mehreren Punkten innerhalb oder zwischen Client und Server cachefähig sein. Wurde auf Seiten des Servers eine bestimmte Ressource bereitgestellt, die innerhalb einer gewissen Zeit wahrscheinlich erneut angefordert wird, so sollte diese für eine schnellere Antwortzeit im Cache gespeichert werden. Der Client sollte eine ähnliche Entscheidung treffen, was erhaltene Ressourcen betrifft. Der Server sollte dabei über die API angeben, ob eine Ressource sicher lokal vom Client zwischengespeichert werden kann, und gegebenenfalls die Lebenszeit der Daten mitteilen. Das Design des Cache ist zwar nicht Teil der Eigenschaften einer RESTful API, aber dennoch grundlegend für die Leistung des Systems. API-Entwickler sollten sich darüber im Klaren sein und bedenken, welche Auswirkungen dies in der Praxis haben kann.

5. Mehrschichtige Systemarchitektur

Aufgrund der strikten Trennung von Client und Server, der Zustandslosigkeit und der Cachefähigkeit kann ein Client nicht erkennen, ob er direkt mit dem Server, der eine bestimmte Ressource bereitstellt, kommuniziert, oder ob er von einem zwischengeschalteten System wie einem Service Broker, einem Load Balancer, einem Content Delivery System oder einem anderen Subsystem bedient wird, das sich näher am Client befindet als der Server. Dies bietet System- und Infrastrukturentwicklern eine beachtliche Flexibilität, um die Effizienz und Zuverlässigkeit der Anfragenbearbeitung über die globale kabelgebundene und drahtlose Infrastruktur hinweg zu maximieren. Das wiederum ist die Grundlage der Funktionalität des Edge Computing.

6. Code on demand

Während REST APIs nur Daten zur Verarbeitung durch den Client liefern können (was sie auch häufig tun), so kommt es doch immer öfter vor, dass auch Code geliefert wird, der auf dem Client ausgeführt werden soll, zum Beispiel Java-Objekte oder Javascript-Webanwendungen. Wird diese Funktion bereitgestellt, kann ein solcher Code nur auf Aufforderung des Clients hin ausgeführt werden.

REST APIs können praktisch jede Zugriffsanfrage, jedes Datenformat, jede Ressourcenkontrolle und jede Statusmeldung verarbeiten. Die Regel der Zustandslosigkeit bedeutet jedoch, dass jede Anfrage die zur Verifizierung der Anfrage erforderliche Authentifizierung, die genaue Definition der angeforderten Ressource und die genaue geforderte Aktion enthalten muss.

Beispiel: Eine Dateisystem-API ohne RESTful-Architektur kann auf eine Lesezugriff-Anfrage für eine Datei mit einem Datei-Handle antworten. Dieser Token wird einer Sitzung zugewiesen, damit der Client nur durch Verweis auf diesen Handle mehrfach Lesezugriff erhalten kann. Eine REST API müsste stattdessen jedes Mal die Client-Autorisierung, aber auch die vollständige exakte Ressourcenkennung sowie die genaue Position der zu lesenden Daten innerhalb der Datei senden. Die Nachverfolgung ist dabei Aufgabe des Clients.

REST APIs übermitteln alle diese Informationen durch eine Kombination aus Headern und Parameterfeldern und können die eigentlichen Daten in jedem beliebigen Format austauschen. Ein besonders gebräuchlicher Standard ist JSON, das Javascript-Object-Notation-Format, das trotz seines Namens sowohl von Menschen als auch von Maschinen gelesen werden kann, sei es mit den Augen oder mithilfe einer der verbreiteteren Programmiersprachen.

In der Entwicklung von REST APIs muss besonders auf Effizienz geachtet werden, vor allem wenn große Datentransfers oder zeitkritische Streams, oder umgekehrt kleinere Datenmengen aus ressourcenbeschränkten Quellen wie IoT-Systemen verarbeitet werden sollen.

Die OVHcloud API ist ein Webservice, mit dem OVHcloud Kunden ihre OVHcloud Produkte erwerben, verwalten und konfigurieren können, ohne das grafische Kundeninterface zu verwenden. Sie basiert auf der neuesten RESTful API und macht es so möglich, praktisch alles im OVHcloud Universum zu verwalten. Die API wurde so konzipiert, dass sie besonders benutzerfreundlich und einfach zu verwenden ist, und es stehen Code-Snippets in vielen verschiedenen Sprachen zur Verfügung.

Das OVHcloud Kundencenter (Manager v6) ist jetzt über die OVHcloud API erreichbar, und jedes neue Produkt und jede neue Produktversion wird mit der API kompatibel sein. Die API kann mit der API-Explorer-Konsole durchsucht werden, um alle verfügbaren Funktionen für OVHcloud Produkte zu finden – und das gilt auch für diejenigen, die nicht als Entwickler registriert sind. Sie können auch ein bestimmtes Produkt auswählen und die zugehörige API nach relevanten Aktionen durchsuchen.

Die Verwendung der OVHcloud RESTful API ermöglicht eine schnelle, unkomplizierte Entwicklung von Skripten für maßgeschneiderte Funktionen, Automatisierung, mehrere simultane Tasks und die Erstellung von IaaS-/PaaS-Deployment- und Managementtools. Explizite Sprachunterstützung ist vorhanden für C, C++, C#, Java, Perl, PHP, Python, Ruby und viele mehr.