1 Einleitung
Es gibt unzählige Wege, um Systeme miteinander zu verbinden. Wenn Sie schon eine Weile als Entwickler oder Architekt in der IT-Branche tätig sind, haben Sie eine Reihe davon wahrscheinlich persönlich miterlebt: einfache Kommunikation über Sockets, Shared Memory oder Named Pipes, Abstraktionen wie Remote Procedure Call (RPC), proprietäre oder standardisierte Ansätze wie DCOM und CORBA, RMI und Webservices. Warum sollten Sie sich mit einem weiteren Ansatz beschäftigen? Eine ähnliche Frage hat sich wohl jeder gestellt, als er (oder sie) das erste Mal von »REST« hörte. Was soll daran schon neu oder anders sein? Ist es nicht völlig irrelevant, welche Technologie man einsetzt? Sind die Architekturmuster nicht die gleichen?
1.1 Warum REST?
Nach einer durchaus längeren Phase der Skepsis sind wir zu dem Ergebnis gekommen, dass sich hinter REST [Fielding2000] tatsächlich etwas Neues verbirgt. Wir sind überzeugt davon, dass viele der Innovationen, die im Kontext der Erfindung des WWW entstanden sind, revolutionäre Auswirkungen auf die Architektur unserer IT-Systeme haben können. Dazu gehören keine prophetischen Fähigkeiten – kaum jemand wird bestreiten, dass das WWW tatsächlich eine bahnbrechende technologische Entwicklung war. Aber obwohl wir alle das Web täglich benutzen und man daher annehmen könnte, dass wir es verstanden haben, nutzen wir häufig sein Potenzial bei Weitem nicht aus. Das gilt sowohl für Anwendungen, die über eine Weboberfläche verfügen, wie für verteilte Systeme, die auf Basis von Webtechnologien miteinander kommunizieren. Der Grund dafür ist eine unzureichende Kenntnis der Webarchitektur mit ihrem wichtigsten Protokoll HTTP [RFC7230]1, die ihrerseits wiederum eine konkrete Ausprägung des Architekturstils REST ist2.
Wenn Sie bislang mit Technologien wie verteilten Objekten (Distributed Objects) oder entfernten Prozeduraufrufen (Remote Procedure Call) gearbeitet haben, werden Ihnen viele Ideen aus REST sehr ungewöhnlich erscheinen. Aber auch wenn Sie bereits Webanwendungen entwickelt haben und HTTP, URIs3 und viele andere Standards aus diesem Umfeld zu kennen glauben, ist die Wahrscheinlichkeit groß, dass Sie diese nicht konform zu den REST-Prinzipien eingesetzt haben. Zumindest ging es uns so, als wir uns das erste Mal mit REST auseinandersetzten.
In den folgenden Abschnitten möchten wir Sie davon überzeugen, dass es sich lohnt, einer bestimmten Klasse von Problemen mit dem Lösungsansatz REST zu begegnen. Schauen wir uns dazu zunächst einmal an, mit welchen Problemen man sich bei der Gestaltung verteilter Systeme, sowohl im Unternehmen wie auch über Unternehmensgrenzen hinweg, typischerweise auseinandersetzen muss und welchen Beitrag REST und HTTP dazu leisten.
1.1.1 Lose Kopplung
Wenn Sie zwei Systeme so eng aneinander koppeln, dass sie nicht mehr trennbar sind, haben Sie sie zu einem System verschmolzen. Auch wenn das manchmal sogar sinnvoll sein mag: In den meisten Fällen möchten Sie eine modulare Welt von möglichst unabhängigen Teilsystemen anstelle von monolithischen Riesensystemen, die wir nur im Ganzen oder überhaupt nicht einsetzen, aktualisieren, modifizieren oder außer Betrieb nehmen können. Wir bemühen uns deshalb, Systeme über Schnittstellen miteinander kommunizieren zu lassen und sie dabei voneinander zu isolieren. Am unabhängigsten sind zwei Systeme, wenn sie überhaupt nicht gekoppelt sind – sprich: gar nicht miteinander kommunizieren. Ist dies nicht möglich, sollten wir eine Kopplung anstreben, die nur so eng ist, wie es für eine effiziente Kommunikation unbedingt notwendig ist.
Der Begriff »Lose Kopplung« wurde in den vergangenen Jahren insbesondere im Zusammenhang mit serviceorientierten Architekturen (SOA) stark strapaziert. SOA als Konzept wird häufig mit der technologischen Umsetzung durch Webservices auf Basis von SOAP und WSDL assoziiert. Tatsächlich aber führen gerade entscheidende Unterschiede im REST-Modell, wie die uniforme Schnittstelle und Hypermedia – also die Verknüpfung mithilfe von Links –, zu einem erheblichen Mehrwert bei der Entkopplung von Systemen und Services. Auch REST ist kein Wundermittel und kann die Kopplung zwischen zwei Systemen nicht vollständig verhindern, sie lässt sich aber erheblich reduzieren.
Wenn das für Sie zu schön klingt, um wahr sein zu können, hilft vielleicht ein Blick auf den verbreitetsten aller REST-Clients: Der Webbrowser, den Sie tagtäglich benutzen, ist an keinen bestehenden Server konkret gekoppelt, sondern auf Basis der uniformen Standardschnittstelle in der Lage, mit beliebigen Servern zu kommunizieren, die ihre Dienste über HTTP zur Verfügung stellen. Wir werden sehen, dass es eines der zentralen Ziele bei der Entwicklung von Systemen nach dem REST-Stil ist, diese Art der Entkopplung zwischen Kommunikationspartnern zu erreichen.
1.1.2 Interoperabilität
Interoperabilität, die Möglichkeit zur Kommunikation von Systemen mit technisch stark unterschiedlicher Implementierung, ergibt sich aus der Festlegung auf gemeinsame Standards. So ist die Steckdose in der Wand kompatibel mit dem Netzstecker eines Gerätes, zumindest, wenn sich beide an Standards aus dem gleichen Geltungsbereich, dem gleichen »Ökosystem«, halten. In dieser Beziehung sind die Standards des Web – HTTP, URIs, XML, aber auch HTML u.a. – unschlagbar: Keine andere Softwaretechnologie ist in Bezug auf die Größe des Geltungsbereichs so umfassend wie HTTP4. Im Umkehrschluss kann die Festlegung auf eine bestimmte Technologie zur Hürde für die Kommunikation mit einem System werden. Selbst definierte Binärprotokolle, der Austausch von CSV-oder XML-Dateien, kommerzielle Middleware-Produkte, COM, CORBA, RMI oder SOAP über HTTP: Jeder dieser Ansätze bringt seine eigene Komplexität und seine eigenen Anforderungen an die Umgebung der Kommunikationspartner mit sich. HTTP als Protokoll und URIs als Identifikationsmechanismus werden in praktisch jeder Umgebung unterstützt, vom Großrechner bis zum Embedded-System (in meinem WLAN-Router z. B. arbeitet ein HTTP-Server). Kein anderes Applikationsprotokoll ist HTTP in Bezug auf die Interoperabilität überlegen.
1.1.3 Wiederverwendung
Schon andere Technologien wurden damit beworben, durch massiv höhere Wiederverwendungsraten die Kosten in der Softwareerstellung zu senken – seien es Objekte, Komponenten oder Services. Bei der Entwicklung von REST-Anwendungen spielen zwei Faktoren hier eine zusätzliche Rolle: die Möglichkeit von sich überlappenden Schnittstellen und die Unterstützung der ungeplanten Wiederverwendung (»serendipitous reuse«) [Vinoski2008].
Ein typisches Problem bei einem Entwurf, der eine später Wiederverwendung unterstützen soll, ist die mangelhafte Vorhersehbarkeit der Anforderungen. Nahezu alle bereits oben aufgezählten Technologien zielen darauf ab, eine klare, formal definierte Schnittstelle für jede spezifische Anwendung zu erfinden. Schnittstellendesign ist jedoch keine leichte Aufgabe – idealerweise vereinheitlicht man eine Reihe bestehender Lösungen, erprobt das Ergebnis und standardisiert es anschließend. Bei REST gibt es nur eine Schnittstelle. Dadurch kann jeder Client, der diese Schnittstelle verwenden kann, mit jedem REST-basierten Service kommunizieren (unter der Voraussetzung, dass das Datenformat von beiden Seiten verstanden wird).
1.1.4 Performance und Skalierbarkeit
Benutzergesteuerte Anwendungen und von anderen Programmen aufgerufene Dienste sollen schnell antworten – so schnell wie möglich. Gleichzeitig soll eine größtmögliche Anzahl von Anfragen in einem definierten Zeitraum beantwortet werden können.
Wie performant und skalierbar eine Anwendung oder ein Service ist, hängt vor allem von der Architektur ab, und zwar auf zwei Ebenen: zum einen der internen Architektur, also der der Implementierung, zum anderen der Verteilungsarchitektur, also der Art und Weise, wie die auf mehrere Prozesse auf unterschiedlichen Rechnerknoten verteilten Komponenten über das Netz miteinander kommunizieren. REST und HTTP haben keinen oder zumindest nur einen geringen Einfluss auf die interne Implementierungsarchitektur, aber einen sehr großen Einfluss auf die externe Verteilungsarchitektur.
Die Infrastruktur des Web kann ihre Stärken optimal ausspielen, wenn die externe Schnittstelle eines Systems auf Basis von HTTP konform zu den REST-Prinzipien entworfen wird. Eine Vielzahl von Anfragen können aus einem Cache beantwortet werden, andere wiederum werden minimiert oder ganz vermieden. Die Skalierbarkeit wird durch den Verzicht auf einen sitzungsbezogenen Status deutlich verbessert – aufeinander folgende Anfragen müssen nicht zwingend vom gleichen System beantwortet werden.
1.2 Zielgruppe und Voraussetzungen
Dieses Buch richtet sich an Architekten, Designer und Entwickler, die »RESTful Services« für die Implementierung einer verteilten Anwendung oder Anwendungslandschaft einsetzen wollen, eine bestehende Webanwendung um eine externe Schnittstelle (ein »Web-API«) erweitern möchten oder ganz...
