REST als Architekturstil

Es ist nicht ungewöhnlich, dass Entwickler, anstatt ein neues Projekt von Grund auf zu entwickeln, an der Erweiterung bereits existierender Software arbeiten müssen. In der Regel kommunizieren solche Programme in verteilten Systemen über Schnittstellen mit anderen Programmen, wobei REST-basierte Schnittstellen am häufigsten verwendet werden. Trotz der Einfachheit des Fielding’s-Legacy-Architekturstils, der allgemein auch als REST-Architektur bezeichnet wird, sind Endpunkte wie /createUser oder /deleteContact­OfUser weit verbreitet, was darauf hindeutet, dass die Prinzipien dieser Architektur entweder nicht bekannt sind oder nicht befolgt werden.Ein Beispiel für eine Schnittstellenbeschreibung ist /api/v1/user/change: Ein POST-Request, der Benutzerdaten erhält, die für einen Benutzer geändert werden sollen. User-Daten sowie User-ID werden in einem JSON-Objekt übergeben. Es ist jedoch darauf hinzuweisen, dass diese Beschreibung in vielerlei Hinsicht falsch ist, was in diesem Artikel näher erläutert wird.Die REST-Architektur, auch bekannt als Representational State Transfer, ist ein Architekturstil für verteilte Systeme. Sie wurde im Jahr 2000 von Roy Fielding in seiner Doktorarbeit „Architectural Styles and the Design of Network-based Software Architectures“ [1] eingeführt und hat sich seitdem als ein weit verbreiteter Ansatz für die Gestaltung von Schnittstellen etabliert. REST basiert auf einer Reihe von Prinzipien und Best Practices, die darauf abzielen, skalierbare, ­wartbare und einfach zu verwendende Schnittstellen zu entwickeln.

Fieldings Vermächtnis: Die REST-Architektur

Diese Architektur lässt sich in folgenden sechs grundlegenden Prinzipien darstellen:Das erste Prinzip der REST-Architektur ist die strikte Entkopplung von Client und Server. Dieses Prinzip wird auch Client-Server-Architekturprinzip genannt. Diese Trennung erlaubt es, dass die Benutzeroberfläche (Client) unabhängig von der Backend-Logik und der Datenverarbeitung (Server) entwickelt und weiterentwickelt werden kann. Durch die Entkopplung von Client und Server können beide Komponenten unabhängig voneinander skaliert und verbessert werden. Dieses Prinzip fördert auch die Portabilität von Benutzeroberflächen auf verschiedene Plattformen und eine einfache Kommunikation zwischen unterschiedlichen Backend-Systemen.Das zweite Prinzip ist die Zustandslosigkeit (Stateless). Jede Anfrage eines Clients an den Server muss alle Informationen enthalten, die der Server benötigt, um die Anfrage zu verstehen und darauf zu reagieren. Dies bedeutet, dass der Server keine Informationen über den aktuellen Zustand des Clients speichern darf. Zustandslosigkeit ermöglicht eine bessere Skalierbarkeit, da der Server keine Zustandsinformationen verwalten muss und dadurch mehr Ressourcen für die Verarbeitung von Anfragen zur Verfügung hat.Man spricht hier gerne auch über die lose Kopplung. Zudem vereinfacht dies die Architektur und ermöglicht eine höhere Fehlertoleranz, da keine Zustandsinformationen verloren gehen können.

Das dritte Prinzip behandelt die Cache-Fähigkeit (Cache­ability): Die REST-Architektur erlaubt die Verwendung von Caching-Mechanismen, um die Leistung und Skalierbarkeit des Systems zu verbessern. Clients können Zwischenspeicher (Caches) verwenden, um Antworten auf Anfragen temporär zu speichern und bei Bedarf erneut abzurufen, ohne den Server erneut kontaktieren zu müssen.Gerade im Hinblick auf Authentifizierung beziehungsweise Sessions kommt das Prinzip der Cacheability zum Einsatz. Es reduziert die Last auf dem Server und ermöglicht kürzere Antwortzeiten. Um effektives Caching zu ermöglichen, müssen die Server explizit angeben, welche Daten zwischengespeichert werden können und wie lange diese Daten gültig bleiben.Ein Beispiel für Caching ist eine Session, welche auf einem Token basiert. Der Token wird an jeden Request angehängt. Der Token beinhaltet immer ein Ablauf-Attribut, damit der Client weiß, wie lange dieser Token noch gültig ist und ihn gegebenenfalls bei einer nächsten Anfrage beim Server verlängern kann.Das vierte Prinzip beschreibt einheitliche Schnittstellen: Um die einfache Interaktion zwischen unterschiedlichen Komponenten des Systems zu ermöglichen, definiert die REST-Architektur eine einheitliche Schnittstelle zwischen Client und Server. Die Schnittstelle besteht aus vier Hauptkonzepten:

• Ressourcenidentifikation in Anfragen,
• Manipulation von Ressourcen durch Repräsentationen,
• selbstbeschreibende Nachrichten und Hypermedia als Triebfeder der Anwendung (HATEOAS siehe unten).
• Eine einheitliche Schnittstelle vereinfacht und entkoppelt die Architektur, was die Entwicklung und Weiterentwicklung von Komponenten erleichtert.

Alle diese Uniform Resource Identifiers (URIs) sind ressourcenbasiert. Die Ressource users ist hier das Subjektiv und wird über die userId ausgewählt. Somit ist es möglich, die Ressourcenbezeichner publications, posts und profile beliebig zu erweitern.Das fünfte Prinzip befasst sich mit mehrschichtigen Systemen (Layered Systems):  Die REST-Architektur fördert den Einsatz von mehrschichtigen Systemen, bei denen einzelne Schichten unterschiedliche Funktionen übernehmen. Jede Schicht kommuniziert nur mit den direkt angrenzenden Schichten, was dazu führt, dass die Komplexität der einzelnen Schichten reduziert wird. Dadurch lässt sich die System­entwicklung vereinfachen und die Wartbarkeit spürbar verbessern.Eine typische mehrschichtige Architektur umfasst eine Präsentationsschicht – die Benutzeroberfläche –, eine Geschäftslogikschicht und eine Datenspeicherschicht. In solchen Systemen können zusätzliche Schichten hinzugefügt werden, um die Systemfunktionalität zu erweitern und die Skalierbarkeit zu verbessern. Typische Beispiele dafür sind Caching-, Sicherheits- oder Lastverteilungsschichten. Bild 1 skizziert eine Anwendung mit vier Schichten.

Das sechste Prinzip der REST-Architektur, Code auf Anfrage (Code on Demand), ist optional und ermöglicht es dem Server, ausführbaren Code an den Client zu senden. Dieser Code kann daraufhin vom Client ausgeführt werden, um dessen Funktionalität zu erweitern oder anzupassen.Dieses Prinzip ermöglicht eine flexiblere und anpassungsfähigere Architektur, bei welcher der Client seine Funktionen basierend auf den Anforderungen des Servers ändern kann. Typischerweise wird der Code-on-Demand-Ansatz in Form von JavaScript- oder WebAssembly-Code verwendet, der vom Server bereitgestellt und im Webbrowser des Clients ausgeführt wird. Dieses Prinzip sollte jedoch mit Bedacht eingesetzt werden, da es Sicherheits- und Leistungsherausforderungen mit sich bringen kann.

Das Richardson Maturity Model

Die REST-Prinzipien dienen als strukturiertes Bewertungs- und Klassifizierungssystem für RESTful APIs. Es ist jedoch wichtig zu beachten, dass es einen Unterschied zwischen REST und RESTful gibt. Das Richardson Maturity Model (RMM) wurde von Leonard Richardson entwickelt und später von Martin Fowler und Roy Fielding bekannt gemacht [2].Es besteht aus einer aufeinanderfolgenden Hierarchie von vier Reifegradstufen, die den Grad der Übereinstimmung eines APIs mit den REST-Prinzipien widerspiegeln. Das Modell hilft dabei, den Unterschied zwischen einfachen HTTP-basierten APIs und „echten“ RESTful-APIs zu verdeutlichen, indem es verschiedene Reifegrade für die Umsetzung der REST-Prinzipien in API-Designs bietet.

Stufe 0: POX (Plain Old XML)

In dieser Stufe sind APIs auf dem niedrigsten Reifegrad und nutzen lediglich einen einzigen URI und eine einzige ­HTTP-Methode (normalerweise POST) für alle Anforderungen. Die Interaktion mit dem Service ist stark an die Verwendung von XML gebunden, wodurch die Nutzung und Wartung der APIs schwierig und unübersichtlich werden kann.

Stufe 1: Ressourcen (Subjektive)

In der ersten Stufe werden die verschiedenen Ressourcen (Users, Publications, Images, Posts) des APIs identifiziert und separate URIs für jede Ressource erstellt. Dadurch wird das API besser organisiert und ist einfacher zu verstehen. Allerdings werden immer noch nur eine oder wenige HTTP-Methoden verwendet, wodurch das API den REST-Prinzipien noch nicht vollständig entspricht.Per Definition ist somit eine Ressource ein Objekt mit einem Typ, zugeordneten Daten sowie Beziehungen zu anderen Ressourcen und zusätzlich einer Reihe von Methoden, die damit arbeiten.

Stufe 2: HTTP-Verben

Auf der zweiten Stufe werden die verschiedenen HTTP-Methoden (zum Beispiel GET – getOne, getAll, POST – create, PUT – update, DELETE – delete) konsequent verwendet, um Aktionen auf den Ressourcen durchzuführen. In diesem Zusammenhang spricht man auch von HTTP-Verben statt von HTTP-Methoden. Sie werden auch CRUD-Operationen genannt. Dies ermöglicht es, die API-Interaktionen auf eine standardisierte und intuitive Weise zu gestalten, indem die Funktionen der HTTP-Methoden ausgenutzt werden. Das API wird somit leichter verständlich und besser wartbar.

Stufe 3: Hypermedia Controls (HATEOAS)

Die höchste Stufe des Richardson Maturity Models beinhaltet die Implementierung von Hypermedia as the Engine of Application State, kurz HATEOAS. Dieser Grundsatz besagt, dass ein RESTful API dem Client nicht nur Daten zurückgeben soll, sondern auch Links zu anderen Ressourcen, die der Client verwenden kann, um weitere Aktionen auszuführen.In dieser Stufe des APIs sind alle Ressourcen durch eindeutige URIs identifiziert. Der Server sendet dem Client jedoch nicht nur die Daten einer Ressource zurück, sondern auch Links zu anderen Ressourcen, auf die der Client zugreifen kann. Diese Links geben dem Client Informationen darüber, welche Aktionen als Nächstes ausgeführt werden können und welche Ressourcen verfügbar sind.Durch die Verwendung von HATEOAS wird die Client-Server-Kommunikation flexibler und dynamischer gestaltet, da der Client nicht auf vordefinierte Aktionen beschränkt ist, sondern durch die Links auf andere Ressourcen navigieren und auf diese zugreifen kann. In den meisten Fällen geschieht dies bei lesenden Operationen (GET). Dadurch wird auch die Skalierbarkeit des APIs verbessert, da Änderungen an der Serverstruktur oder an den URIs nicht unbedingt Auswirkungen auf den Client haben müssen, solange die Links korrekt sind.Insgesamt trägt HATEOAS dazu bei, die Interoperabilität und Flexibilität von RESTful APIs zu verbessern und stellt damit einen wichtigen Grundsatz des REST-Architekturstils dar.Interoperabilität ist ein wichtiges Ziel bei der Entwicklung von Systemen oder Anwendungen, insbesondere in der Kommunikation zwischen verschiedenen Systemen oder Anwendungen. Eine interoperable Architektur stellt sicher, dass Informationen und Dienste zwischen verschiedenen Systemen ausgetauscht werden können, ohne dass es zu Problemen oder Inkompatibilitäten kommt. Interoperabilität ist auch wichtig für die Skalierbarkeit und Flexibilität von Systemen, da sie es ermöglicht, neue Komponenten oder Systeme nahtlos in bestehende Architekturen zu integrieren, ohne dass dabei die Funktionalität oder Stabilität beeinträchtigt wird.In diesem Zusammenhang dient das Richardson Maturity Model als Brücke zwischen den grundlegenden REST-Prinzipien und der praktischen Umsetzung dieser Prinzipien in konkreten APIs. Es hilft Entwicklern, den Weg zu einem REST-konformen API schrittweise und strukturiert zu verfolgen, indem sie die verschiedenen Reifegradstufen als Orientierung nutzen und ihr API-Design entsprechend optimieren, siehe Bild 2.

Paradigmen und serviceorientierte Architekturen

Dieses Architekturparadigma steht in engem Zusammenhang mit der serviceorientierten Architektur (SOA), da sie sich beide mit der Strukturierung und Organisation von Webservices beziehungsweise APIs auseinandersetzen. SOA ist ein Architekturparadigma, das darauf abzielt, die Geschäftsfunktionalität in Form von wiederverwendbaren und losen gekoppelten Diensten zu organisieren. Jeder Dienst ist für ­eine bestimmte Geschäftsfunktion oder einen bestimmten Prozess verantwortlich und kommuniziert über standardisierte Schnittstellen, wie beispielsweise Webservices, mit anderen Diensten.REST ist eine der möglichen Implementierungen für serviceorientierte Architekturen und hat sich als ein populärer Ansatz für das Erstellen von Web-APIs etabliert.In diesem Kontext kann das Richardson Maturity Model als ein Hilfsmittel betrachtet werden, um RESTful APIs im Rahmen einer serviceorientierten Architektur zu bewerten und zu verbessern. Indem Entwickler den Reifegrad ihrer APIs nach dem Richardson Maturity Model erhöhen, können sie sicherstellen, dass die APIs besser den Prinzipien von REST entsprechen und dadurch eine effiziente Kommunikation zwischen den Diensten in einer SOA ermöglichen. Durch die Verwendung des Richardson Maturity Models können Entwickler somit die Stärken und Schwächen ihrer APIs im Hinblick auf die Einhaltung der REST-Prinzipien erkennen und gezielt Verbesserungen vornehmen. Dies führt zu einer besseren Benutzererfahrung und erhöht die Effizienz der API-Kommunikation.

Was ist aber nun der Unterschied zwischen REST und RESTful?

REST und RESTful sind eng miteinander verwandte Begriffe, die oft synonym verwendet werden. Der Hauptunterschied zwischen den beiden liegt jedoch in der Erfüllung des Richardson Maturity Models.REST bezieht sich auf den Architekturstil, der auf URIs, also Ressourcen (Subjektive) und der Verwendung von HTTP-Methoden (Verben) basiert.RESTful bezieht sich auf eine Implementierung von REST, die alle Prinzipien von REST erfüllt, einschließlich der Verwendung von HTTP-Methoden, URIs und der Unterstützung von Hypermedia. Mit anderen Worten, RESTful APIs erfüllen alle Stufen beziehungsweise Reifegrade des Richardson Maturity Models und sind damit als vollständig REST-konform zu betrachten.Es ist jedoch wichtig zu beachten, dass RESTful nicht gleichbedeutend mit REST-konform ist. Ein API kann RESTful sein, ohne vollständig REST-konform zu sein, wenn beispielsweise nur einige, aber nicht alle Prinzipien von REST erfüllt sind. In der Praxis wird der Begriff REST oft locker verwendet, um sich auf RESTful APIs zu beziehen. Beide Begriffe beziehen sich auf den gleichen Architekturstil und dessen Umsetzung, unterscheiden sich jedoch in der Tiefe und Vollständigkeit der Implementierung.

Fazit

Zusammenfassend kann gesagt werden, dass SOA, REST und das Richardson Maturity Model eng miteinander verknüpft sind, da sie sich alle mit der Organisation und Strukturierung von Diensten und APIs beschäftigen. Dabei stellt SOA das übergeordnete Architekturparadigma dar, während REST eine mögliche Implementierung für eine SOA ist und das Richardson Maturity Model als Bewertungswerkzeug für RESTful APIs dient.

Fussnoten

1. Fielding, Roy Fielding’s REST dissertation, https://oleb.net/2018/rest
2. Martin Fowler, Richardson Maturity Model, http://www.dotnetpro.de/SL2309REST1