Veröffentlicht am: Oktober 16, 2024
8 Minuten Lesezeit
REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server und Client. Erfahren Sie hier alles Wissenswerte zum Thema!
REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs), die den Austausch von Daten zwischen Client und Server regeln. REST-APIs unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST (representational state transfer) festgelegt hat.
REST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest. Fielding hat REST vielmehr als einen „Architektur-Stil“ bezeichnet, der eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.
In diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung zum dominanten Modell entwickelt hat und welche Vorteile sich für Web-Development-Teams daraus ergeben.
REST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen) auf.
Aus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben kann.
REST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein Client-Server-Modell erstellt werden:
In den folgenden Abschnitten betrachten wir diese Constraints genauer.
REST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass Client und Server vollkommen unabhängig voneinander bleiben.
So kann beispielsweise der Code des Servers verändert werden, ohne dass der Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen anfragen und erhalten zu können.
Die Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte Beantwortung einer Anfrage die übermittelten Informationen der aktuellen Sitzung ausreichen.
Das bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht zwischengespeichert werden.
Zustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit. Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut eingeben werden.
Für jedes Unternehmen ist eine andere Server-Struktur optimal. Werden Informationen beispielsweise in verschiedenen Schichten gespeichert, gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt werden.
Die Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client nichts weiter benötigt als die Anfrageinformationen, verlangt das mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie der Server die angeforderten Daten bereitstellt.
Der Server kann also mit einer Vielzahl verschiedener Architekturen arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird.
Diese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten REST-API-Architektur.
Die einheitliche Schnittstelle fordert:
Die einheitliche Schnittstelle sorgt für maximale Klarheit und eine einfache, standardisierte Client-Server-Kommunikation.
Zwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt, zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf demselben Endgerät weiterverwendet werden können.
Indem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine höhere Effizienz und beschleunigt viele Prozesse bedeutend.
Für die meisten Anwendungen reicht die Bereitstellung der Daten in der Form von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von Vorteil sein, dem Client darüber hinaus – oder stattdessen – eine Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.
Code on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar, aber sie ist als einzige der sechs Einschränkungen optional.
Flexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele praktische Anwendungen denkbar:
Im Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können. Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum Datenaustausch im Netz.
In den frühen Tagen des Internets war SOAP (Simple object access protocol) die dominante Form des Datenaustauschs.
Dass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten Vorteilen erklären:
Auch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt. Aus diesem Grund stellen wir unseren Nutzer(inne)n eine GitLab-REST-API zur Verfügung.
Bei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen. Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ an Entwicklungsprojekten zu arbeiten.
Die GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung) abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der Austausch sicher, schnell und effizient.
REST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben entsprechen, sind „RESTful“. Es ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch realisiert werden.
Aus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert.
Roy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach Stellung bezogen. Seine Ansichten zu dieser Frage sind eindeutig: REST ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos umgesetzt werden.
Eine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber keine Daten gecached werden können, ist nicht RESTful.
Die einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien erfüllt.
Zwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von Daten im Cache dann nicht dieser Forderung?
In Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der Daten im Cache zu einer aktuellen Anfrage.
Das Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für Stabilität.
Wenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil oder der Code fehlerhaft ist.
Entscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler bei der Beantwortung der Anfrage führt.
Die Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen als solche erkannt und fehlerfrei bearbeitet werden können.
REST-APIs können sehr effektiv gesichert werden.
Übliche und sehr effiziente Methoden sind die Verwendung von HTTPS und API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen sowie die Durchführung einer Input-Validation und eines Audit-Loggings.
Auch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne eines Rate-Limiting empfiehlt sich.