© Excellent backgrounds/Shutterstock.com
Nachhaltige Webarchitekturen

REST und SPAs sind nicht immer die Lösung


Heutzutage gewinnt man leicht den Eindruck, dass es für moderne Webanwendungen nur einen einzig wahren Architekturansatz gibt: REST und Single-Page-Anwendungen (SPAs). Doch ist alles, was REST genannt wird, wirklich REST? Sind REST und SPAs immer die beste Lösung? Um diese Fragen beantworten zu können, sollte man sich anschauen, was REST eigentlich ist, wofür es gedacht ist und ob es möglicherweise Alternativen zu SPAs gibt; insbesondere mit dem Blick auf Nachhaltigkeit, im Sinne von Wartbarkeit und Erweiterbarkeit.

REST [1] wurde von Roy Fielding in seiner Dissertation [2] im Jahr 2000 als Architekturstil für verteilte Hypermediasysteme definiert. Dabei ist ein Architekturstil eine Sammlung an Entwurfsrichtlinien, durch die eine Architektur bestimmte Eigenschaften erhält, wie Skalierbarkeit oder lose Kopplung. Doch warum sollten solch akademische Details in der Praxis relevant sein? In der Regel wählen wir Architekturen, weil wir damit gewisse Anforderungen erfüllen wollen. Das heißt, wir sollten sie nicht wählen, weil diese Lösung gerade in aller Munde ist – wie gerade bei Microservices, Single-Page-Anwendungen oder auch REST der Fall –, sondern weil sie unser Problem, so gut es eben geht, lösen. Wenn wir nicht wissen, welche Eigenschaften – sowohl positive als auch negative – ein Architekturstil mit sich bringt, ist es auch wenig sinnvoll, ihn einzusetzen. Als hätte Roy Fielding in die Zukunft blicken können, schreibt er in seiner Dissertation: „Some architectural styles are often portrayed as ‚silver bullet‘ solutions for all forms of software. However, a good designer should select a style that matches the needs of the particular problem being solved.“ [2, Kapitel 1.5]

Wenn man nun also versteht, welche Richtlinien welche Eigenschaften mit sich bringen, hat man die Möglichkeit, den Architekturstil den eigenen Bedürfnissen anzupassen und kann Vor- und Nachteile bewusst gegeneinander abwägen. Denn es ist in Ordnung, bewusst gegen REST-Prinzipien zu verstoßen, solange dann nicht von einer REST-konformen Architektur gesprochen wird. Beim Entwurf einer webbasierten Architektur sollte berücksichtigt werden, welche Eigenschaften REST durch welche Entwurfsrichtlinien bietet und wie diese ineinander greifen.

Die Konsequenzen von Client-Server-Architekturen

Bei der Entwicklung einer Webanwendung bleibt einem gar nichts anderes übrig, als eine Client-Server-Architektur zu wählen. Jedoch werden beim Erfassen der Anforderungen oft die Konsequenzen einer solchen Architektur nicht berücksichtigt. Der große Vorteil von Webanwendung, dass sie sich auf einer Vielzahl von Plattformen und Geräten ohne weitere Installation benutzen lassen, bringt leider auch einige Nachteile mit sich. Der Server kann die Ausführungsumgebung des Clients nicht kontrollieren. Man nimmt entweder in Kauf, viel Aufwand in die Unterstützung von vielen verschiedenen Clients zu investieren, oder dass die Menge der Benutzer reduziert wird. Ein nützlicher, jedoch häufig nicht genutzter Kompromiss ist, zu akzeptieren, dass die Anwendung nicht auf allen Clients identisch aussieht – im Sinne pixelgenauer Positionen – und sich nicht in allen Details identisch verhält. Natürlich sollte sich die Anwendung ähnlich benutzen lassen und wiederzuerkennen sein. Wenn zum Beispiel ein älterer Client kein SVG unterstützt und dies für interaktive Diagramme nötig ist, so bekommt dieser Client nur eine nicht interaktive Variante angezeigt. Es sollte jedoch das Ziel sein, für jeden Client ein möglichst optimales Erlebnis zu bieten, je nachdem, wie weit verbreitet oder wichtig der jeweilige Client ist.

Bei der Entwicklung klassischer Webanwendungen erhalten der Browser und seine Eigenheiten in der Regel viel Aufmerksamkeit. Im Gegensatz dazu werden programmatische Clients in Architekturdiskussionen leider oft außer Acht gelassen. Allerdings beziehen sich viele der Entwurfsrichtlinien von REST auf die Kommunikation von Client und Server und nicht nur auf den Server alleine. Ein Client beziehungsweise seine Implementierung hat deshalb großen Einfluss auf den Erfolg der Gesamtarchitektur.

Natürlich können sich Server und Client unabhängig voneinander weiterentwickeln, jedoch sollte klar sein, dass die Schnittstelle das zentrale Architekturelement ist und dementsprechend behandelt, dokumentiert und getestet werden sollte. Das heißt auch, dass Änderungen an einer Schnittstelle nicht ohne triftigen Grund und unbemerkt passieren sollten. Und wenn dann nur so, dass ein existierender Client weiterhin damit klarkommen kann. Dies stellt aber auch Anforderungen an den Client: Zum Beispiel sollte er ihm unbekannte Daten ignorieren. Genau diese Unabhängigkeit von Client und Server ist eines der Ziele von REST, die allerdings nicht immer gebraucht wird.

Statelessness: einfacher, als man denkt

Eine weitere, oft auf den ersten Blick schwierig umzusetzen erscheinende Entwurfsrichtlinie ist die zustandslose Kommunikation: Dies bedeutet weder, dass es im Server keinen Zustand geben darf, zum Beispiel im Sinne einer Datenbank, noch, dass der Client keinen Zustand haben darf. Stattdessen heißt dies, dass jeder Request alle Informationen enthalten muss, die zur Verarbeitung notwendig sind. Eine Serverinstanz muss somit vorher noch nie mit diesem Client gesprochen haben, um seinen Request beantworten zu können. Auch wenn es zunächst schwer vorstellbar erscheinen mag, lassen sich auch komplexe Prozessflüsse oder Dialoge mit zustandsloser Kommunikation umsetzen. Dabei wird der Zustand entweder über den URI identifiziert, im Client gehalten oder auf dem Server persistiert.

Diese Zustandslosigkeit führt nicht nur zu sehr guter Skalierbarkeit, sondern verbessert auch die Ausfallsicherheit. Denn ohne großen Aufwand können mehrere Serverinstanzen betrieben werden. Die Komplexität beim Entwickeln ist geringer, da bei der Implementierung der Geschäftslogik für die Verarbeitung eines Requests kein großer Zustandsraum berücksichtigt werden muss. Dies führt auch dazu, dass sich jeder Request unabhängig und einfach testen lässt. Außerdem erleichtert es Monitoring und Debugging, da in jedem Request alle Informationen enthalten sind und nicht erst der gesamte Sessionzustand rekonstruiert werden muss. Ein weiterer Vorteil ist, dass ein fehlgeschlagener Request weniger Auswirkungen hat, da er keinen Zustand (einer Session) zerstört und somit zum Beispiel ohne Weiteres wiederholt werden kann.

Caching sinnvoll einsetzen

Eine sehr einfache, aber oft vernachlässigte Entwurfsrichtlinie ist die sinnvolle Verwendung von Caches. Bei jedem Request kann der Server den Client oder andere dazwischen liegende Komponenten darüber informieren, dass die Antwort auf einen Request für eine gewisse Zeit vorgehalten werden kann. Ohne diese Möglichkeit würde das Web deutliche Performan...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang