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. Entwickler können REST-APIs jedoch mit praktisch jeder Programmiersprache entwickeln und eine Vielzahl von Datenformaten 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.

Beim Design von REST-APIs müssen Client- und Serveranwendungen völlig unabhängig voneinander 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. Zum einen bedeutet dies, dass Sie Ihre Clientanwendungen frei verändern können, ohne dass dadurch Änderungen an der Serveranwendung vorgenommen werden. Gleiches gilt auch im umgekehrten Sinne. So lässt sich sicherstellen, dass selbst umfassende Änderungen am Server oder Client keine Kompatibilitätsprobleme verursachen, solange die eigentliche Schnittstelle unangetastet bleibt. Dies führt zu deutlich mehr Flexibilität bei der Entwicklung sämtlicher Komponenten.

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. Basierend auf der mehrschichtigen Architektur lassen sich unterschiedliche Frameworks erstellen, bei denen einzelne Schichten mit verschiedenen Funktionen zusammenarbeiten. So wird die Arbeit mit REST-APIs besonders flexibel und ermöglicht zudem die Implementierung zusätzlicher Sicherheitsschichten.

REST-APIs senden in der Regel statische Ressourcen. In bestimmten Fällen können die Antworten jedoch auch ausführbaren Code enthalten (z. B. Java-Applets). Hier sollte der Code nur bei Bedarf ausgeführt werden, um Sicherheitsrisiken aufgrund von unerwünschtem Code zu vermeiden. Generell wird diese Funktion aktuell aber eher selten genutzt.

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 gelesen werden kann und unabhängig von der Programmiersprache 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 vs. REST API: Was ist der Unterschied?

Obwohl Flexibilität ein großer Vorteil des REST-API-Designs ist, kommt es durch diese auch schneller zur Entwicklung einer fehlerhaften oder schlecht funktionierenden API. Aus diesem Grund folgen 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.