Was ist REST-API?

REST wurde erstmals im Jahr 2000 vom Informatiker Dr. Roy Fielding in seiner Doktorarbeit definiert und bietet Entwicklern ein relativ hohes Maß an Flexibilität, Konsistenz, Skalierbarkeit und Effizienz. REST-APIs bieten eine einfache Möglichkeit zum Erstellen von Web-APIs und werden häufig verwendet, um den Datenaustausch zwischen Anwendungen, Webdiensten und Datenbanken zu erleichtern und Komponenten in Microservices-Architekturen zu verbinden.

In ihrer einfachsten Form ist eine API ein Mechanismus, der es einer Anwendung oder einem Dienst ermöglicht, auf eine Ressource innerhalb einer anderen Anwendung, eines anderen Dienstes oder einer anderen Datenbank zuzugreifen. Die Anwendung oder der Dienst, der auf Ressourcen zugreift, ist der Client, und die Anwendung oder der Dienst, der die Ressource enthält, ist der Server.

Einige APIs, wie SOAP oder XML-RPC, zwingen den Entwicklern ein strenges Framework auf. Aber Entwickler können REST-APIs mit praktisch jeder Programmiersprache entwickeln und verschiedene Datenformate unterstützen. Die einzige Voraussetzung ist, dass sie den folgenden sechs REST-Designprinzipien entsprechen, die auch als architektonische Einschränkungen bezeichnet werden.

Alle API-Anfragen für dieselbe Ressource sollten gleich aussehen, unabhängig davon, woher die Anfrage stammt. Die REST-API sollte sicherstellen, dass ein und dieselbe Information, wie z. B. der Name oder die E-Mail-Adresse eines Nutzers, nur zu einem einzigen Uniform Resource Identifier (URI) – einem einheitlichen Ressourcen-Identifikator – gehört. Die Ressourcen sollten nicht zu groß sein, aber alle für den Kunden notwendigen Informationen enthalten. Hierbei ist es wichtig, dass die Schnittstelle als standardisiertes, unveränderliches Kommunikationsmittel fungiert, da Änderungen ansonsten zu maßgeblichen Problemen bei Anfragen führen und die Funktionalität von Anwendungen beeinträchtigen könnten.

Bei der Entwicklung von REST-APIs müssen Client- und Server-Anwendungen voneinander unabhängig sein. Die einzige Information, die die Clientanwendung kennen sollte, ist der URI der angeforderten Ressource. Sie kann nicht auf andere Weise mit der Serveranwendung interagieren. Ebenso sollte eine Serveranwendung die Clientanwendung nicht verändern und ihr lediglich die angeforderten Daten über HTTP übermitteln.

REST-APIs sind zustandslos. Das bedeutet, dass jede Anfrage alle Informationen enthalten muss, die für ihre Bearbeitung notwendig sind. Mit anderen Worten: REST-APIs erfordern keine serverseitigen Sitzungen. Serveranwendungen dürfen keine Daten speichern, die mit einer Client-Anfrage zusammenhängen. Dies bedeutet beispielsweise, dass Sie nicht zuerst eine Anfrage stellen können, die Sie authentifiziert, um dann im Anschluss mit einer weiteren Anfrage bestimmte Daten ausgeben zu lassen. Stattdessen stellen Sie eine einzelne Anfrage, um sich zu authentifizieren und die gewünschten Daten zu erhalten. Dies reduziert Sicherheits- und Ausfallrisiken und umgeht zudem serverseitigen Speicherbedarf, der durch eine Sitzungsverwaltung entstehen würde.

Wenn möglich, sollten die Ressourcen auf der Client- oder Serverseite gecacht werden können. Die Serverantworten müssen auch Informationen darüber enthalten, ob das Caching für die gelieferte Ressource erlaubt ist. Ziel ist es, die Leistung auf der Client-Seite zu verbessern und gleichzeitig die Skalierbarkeit auf der Serverseite zu erhöhen. Dadurch wird die Notwendigkeit einer konstanten Kommunikation zwischen Client und Server deutlich reduziert, was besonders in Anbetracht der Zustandslosigkeit einen massiven Effizienz- und Geschwindigkeitsvorteil mit sich bringt. Besonders praktisch: Der Server gibt an, wie lange die abgefragten Daten im Cache gespeichert werden können, um auf diese Weise beispielsweise einen Rhythmus für Aktualisierungen festzulegen und so die optimale Balance zwischen Leistung und Aktualität der Daten zu finden.

Bei REST-APIs durchlaufen die Aufrufe und Antworten verschiedene Schichten. Hier gilt die Faustregel, dass man nicht davon ausgehen sollte, dass die Client- und Serveranwendungen direkt miteinander verbunden sind. Bei der Kommunikation kann es eine Reihe verschiedener Zwischenstufen geben. REST-APIs müssen so konzipiert sein, dass weder der Client noch der Server erkennen kann, ob er mit der Endanwendung oder einer zwischengeschalteten Stelle kommuniziert.

PIs senden in der Regel statische Ressourcen. In bestimmten Fällen können die Antworten jedoch auch ausführbaren Code enthalten (wie Java-Applets). In diesen Fällen sollte der Code nur bei Bedarf ausgeführt werden.

REST-APIs kommunizieren über HTTP-Anfragen, um Standard-Datenbankfunktionen wie das Erstellen, Lesen, Aktualisieren und Löschen von Datensätzen (auch als „CRUD“ für Creating, Reading, Updating und Deleting bekannt) innerhalb einer Ressource durchzuführen.

Eine REST-API kann zum Beispiel eine GET-Anfrage verwenden, um einen Datensatz abzurufen. Eine POST-Anfrage erstellt einen neuen Datensatz. Eine PUT-Anfrage aktualisiert einen Datensatz, und eine DELETE-Anfrage löscht einen Datensatz. In API-Aufrufen können alle HTTP-Methoden verwendet werden. Eine gut konzipierte REST-API ist vergleichbar mit einer Website, die in einem Webbrowser mit integrierter HTTP-Funktionalität läuft.

Der Zustand einer Ressource zu einem bestimmten Zeitpunkt, oder Zeitstempel, wird als Ressourcendarstellung bezeichnet. Diese Informationen können einem Client in praktisch jedem Format geliefert werden, einschließlich JavaScript Object Notation (JSON), HTML, XLT, Python, PHP oder einfachem Text. JSON ist beliebt, weil es sowohl von Menschen als auch von Maschinen lesbar ist und sprachenneutral ist.

Anfrage-Header und Parameter sind bei REST-API-Aufrufen ebenfalls von Bedeutung, da sie wichtige Identifizierungsinformationen wie Metadaten, Berechtigungen, URIs, Caching, Cookies und mehr enthalten. Anfrage-Header und Antwort-Header werden in gut konzipierten REST-APIs zusammen mit den herkömmlichen HTTP-Statuscodes verwendet.

GraphQL versus REST API: Was ist der Unterschied?

Obwohl Flexibilität ein wesentlicher Vorteil des REST-API-Designs ist, birgt ebendiese Flexibilität auch die Gefahr, eine fehlerhafte oder leistungsschwache API zu entwickeln. Aus diesem Grund teilen professionelle Entwickler Best Practices in REST-API-Spezifikationen.

Die OpenAPI-Spezifikation (OAS) legt eine Schnittstelle fest, die eine API so beschreibt, dass jeder Entwickler oder jede Anwendung sie erkennen und ihre Parameter und Funktionen vollständig verstehen kann. Diese Informationen umfassen verfügbare Endpunkte, zulässige Operationen für jedes Endgerät, Operationsparameter, Authentifizierungsmethoden und mehr. Die neueste Version, OAS3, enthält praktische Tools wie den OpenAPI Generator, mit dem Sie API-Clients und Server-Stubs in verschiedenen Programmiersprachen erstellen können.

Die Absicherung einer REST-API beginnt ebenfalls mit Best Practices der Branche. Verwenden Sie Hashing-Algorithmen für die Passwortsicherheit und HTTPS für die sichere Datenübertragung. Mit einem Framework wie OAuth 2.0 können die Berechtigungen von Drittanbieteranwendungen eingeschränkt werden.

Mithilfe eines Zeitstempels im HTTP-Header kann eine API auch jede Anfrage ablehnen, die nach einer bestimmten Zeitspanne eintrifft. Die Parametervalidierung und JSON Web Tokens sind weitere Möglichkeiten, mit denen sich sicherstellen lässt, dass nur autorisierte Clients auf die API zugreifen können.