REST
REST (Representational State Transfer) ist ein Paradigma für die Softwarearchitektur von verteilten Systemen, insbesondere für web-basierte Services. Die Grundlagen von REST-Services lauten wie folgt:
- Client-Server
-
REST-Services besitzen die Eigenschaften einer Client-Server-Architektur und folgen diesem Architekturstil.
- Zustandslosigkeit
-
Ein REST-Service speichert zwischen zwei Anfragen keinerlei Zustandsinformationen. Jede Ressource muss alle Informationen enthalten, die für den Server bzw. Client notwendig sind, um sie verarbeiten zu können.
- Caching
-
REST-Nachrichten sollen, entweder explizit oder implizit, angeben, ob sie sich für einen Cache eignen oder nicht.
- Einheitliche Schnittstelle
-
REST-Services besitzen vier Eigenschaften, um einheitlich beschaffen und leicht nutzbar zu sein.
Jede Ressource ist über einen URI eindeutig adressierbar. Damit geschieht der Zugriff für jeden Client eindeutig und für alle nachvollziehbar.
REST-Services können an ihre Clients unterschiedliche Repräsentationen der Ressourcen ausliefern, z. B. in verschiedenen Sprachen oder Formaten. Die Veränderung einer Ressource erfolgt nur über eine dieser Repräsentationen.
Jede Anfrage muss alle Informationen zu ihrer Verarbeitung mitliefern, also selbstbeschreibend sein. Beispiele dazu sind das explizite Kennzeichnen des übertragenen Formats oder die Verwendung von HTTP-Methoden.
Hypermedia as the Engine of Application State (HATEOAS): REST-Services dürfen bei ihren Clients nur minimale Kenntnisse der Schnittstelle voraussetzen. Insbesondere das Navigieren zwischen Ressourcen sollte über Links geschehen, die Teil vorausgehender Ressourcen sind. Die Umsetzung von HATEOAS erzeugt so eine Navigation zwischen Ressourcen ähnlich zur Navigation zwischen Webseiten über Hyperlinks.
- Mehrschichtige Systeme
-
Für Aufrufer von REST-Services muss es transparent sein, welche Systeme zwischen dem Client und dem Server oder hinter der Schnittstelle liegen. Aufrufe ändern sich nicht durch Änderungen an der Infrastruktur (z. B. durch Maßnahmen zur Skalierung) oder durch technische Änderungen, welche nicht den REST-Service selbst betreffen.
|
Einen guten Überblick und Verweise auf detailliertere Beschreibungen bietet die Wikipedia-Seite zu REST. Für einen tiefen Einstieg in die Grundlagen bietet sich die Dissertation von Roy Fielding an. |
Das Richardson Maturity Model ordnet diese Eigenschaften vier Reifegraden zu.
Die IsyFact zielt auf eine möglichst vollständige Umsetzung der Eigenschaften und peilt daher einen hohen Reifegrad für REST-Services an.
Diese Architekturregel hat große Auswirkungen auf die einzelnen Aspekte der Ausgestaltung der REST-Services. Konkret stellt Stufe 2 des Richardson Maturity Models folgende Anforderungen:
-
Ressourcen werden über einen eindeutigen URI angesprochen.
-
Ressourcen werden über HTTP-Methoden angesprochen und je nach HTTP-Methode abgefragt oder verändert.
-
Ressourcen melden ihren Status durch eine Abfrage oder Veränderung über HTTP-Statuscodes zurück.
Stufe 3 des Richardson Maturity Models stellt darüber hinaus weitere Anforderungen:
-
Ressourcen enthalten Verweise auf URIs, mit denen weitere Anfragen im Kontext der Ressource möglich sind.
1. Erlaubte Abweichungen zum Reifegradmodell
In Ausnahmefällen kann auf die Einhaltung der Vorgabe zum Reifegrad verzichtet werden.
1.1. Prozessorientierte Aufrufe - Geschäftsvorfälle
Ein Ausnahmefall stellt die Abbildung von prozessorientierten Aufrufen dar, die häufig durch die Migration von bestehenden prozessorientierten Schnittstellen (z. B. RPC) entstanden sind. Die Abbildung auf einen ressourcenorientierten REST-Service ist i.d.R. mit einer Neukonzeption der Anwendung unter einer ressourcenorientierten Denkweise verbunden. Der Aufwand für die Neukonzeption steht oft nicht im Verhältnis zum tatsächlichen (fachlichen) Nutzen. Aus diesem Grund dürfen prozessorientierte Aufrufe über einfache HTTP-Aufrufe realisiert werden, die bis auf die Ressourcenorientierung und Verwendung der HTTP-Verben, den übrigen Vorgaben des REST-Konzepts folgen. Diese HTTP-Aufrufe entsprechen zwar nicht dem Reifegradmodell (Level 2), sind aber in diesem Ausnahmefall IsyFact-konform.
Wird über die Schnittstelle ein Geschäftsvorfall angestoßen, ist der Geschäftsvorfall in der URI zu adressieren:
| Prozessorientierte URIs | |
|---|---|
Schema |
|
Beispiele |
|