REST und HTTP

Entwicklung und Integration nach dem Architekturstil des Web

Stefan Tilkov, Martin Eigenbrodt, Silvia Schreier, Oliver Wolf

• Verlag: dpunkt
• Jahr: 2015
• ISBN:
  9783864916441
• Auflage: 3
• Thema: Computer Science
• Thema: Software Development

Das Buch bietet eine theoretisch fundierte, vor allem aber praxistaugliche Anleitung zum professionellen Einsatz von RESTful HTTP. Es beschreibt den Architekturstil REST (Representational State Transfer) und seine Umsetzung im Rahmen der Protokolle des World Wide Web (HTTP, URIs und andere).Es wird gezeigt, wie man klassische Webanwendungen und Webservices so entwirft, dass sie im Einklang mit den Grundprinzipien des Web stehen und seine vielen Vorteile ausnutzen.Nach einer kurzen Einleitung, die die Grundprinzipien vermittelt (Ressourcen, Repräsentationen, Hyperlinks, Content Negotiation), wird ein vollständiges praktisches Beispiel vorgestellt. Danach werden die einzelnen Konzepte sowie fortgeschrittene Themen wie Caching, Dokumentation und Sicherheit detailliert betrachtet. Schließlich wird eine erweiterte Form der Beispielanwendung entwickelt, um die Umsetzung der fortgeschrittenen Konzepte zu demonstrieren. Inzwischen etablierte Best Practices zu Entwurf und Implementierung werden in einem eigenen Kapitel beschrieben und diskutiert.Neu in der dritten Auflage ist u.a. die Behandlung von immer populärer werdenden Formaten (wie HAL, collection+json und Siren), Hinweise zur Dokumentation von Web-APIs sowie das Zusammenspiel mit Web-Oberflächen nach dem ROCA-Prinzip.

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]¹, die ihrerseits wiederum eine konkrete Ausprägung des Architekturstils REST ist².

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, URIs³ 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 HTTP⁴. 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 allgemein eine Webanwendung aus Architektursicht optimal gestalten wollen. Wenn Sie eine REST/HTTP-Anwendung entwerfen, müssen Sie sich mit den zugrunde liegenden Standards auseinandersetzen – und dabei lässt es sich nach unserer Überzeugung nicht vermeiden, sich auch in einem gewissen Detaillierungsgrad mit dem zu beschäftigen, was tatsächlich »über die Leitung geht«, also zwischen den an der Kommunikation beteiligten Partnern an Daten ausgetauscht wird.

Sie sollten sich daher nicht erschrecken lassen, wenn Sie im Folgenden mit URIs, HTTP-Anfragen und -Antworten oder den ausgetauschten Daten in XML, JSON oder anderen Formaten konfrontiert werden. Als Voraussetzung für ein Verständnis dieses Buches genügt eine grundlegende Kenntnis von Netzwerken, ein wenig Erfahrung im Umgang mit dem Web und idealerweise noch praktische Erfahrungen im Einsatz einer alternativen Technologie zur Realisierung verteilter Systeme (z. B. CORBA, RMI oder DCOM). Wenn Sie das HTTP-Protokoll bereits näher kennen, werden Sie die für Sie neuen Konzepte leichter verstehen. Kennen Sie HTTP nur oberflächlich, werden Sie im Laufe der Lektüre genug darüber erfahren, um in Zukunft für die meisten Entwickler und Anwender als Experte gelten zu können⁵.

Die konkrete Wahl von Programmiersprache, Bibliotheken oder Webframework spielt für den Entwurf von REST-konformen Systemen keine wesentliche Rolle – zumindest nicht, solange wir uns mit der nach außen sichtbaren Schnittstelle befassen. Natürlich müssen Sie irgendwann eine konkrete Entscheidung treffen, welche Technologien Sie einsetzen (wobei Sie sich bewusst sein sollten, dass Sie sich nicht auf eine einzelne festlegen müssen). Sie finden in Anhang C einige Hinweise für allgemein einsetzbare und plattform- bzw. programmiersprachenspezifische Werkzeuge⁶.

1.3 Zur Struktur des Buches

In den folgenden Kapiteln werden wir uns sowohl mit übergreifenden Fallbeispielen als auch mit den einzelnen Konzepten von REST und HTTP beschäftigen. Die Kapitel im Überblick:

• Kapitel 2: Einführung in REST gibt einen kurzen Überblick die wesentlichen Grundprinzipien und Mechanismen von REST und RESTful HTTP.
• Kapitel 3: Fallstudie: OrderManager stellt anhand einer einfachen Bestellverwaltung vor, wie die Grundprinzipien von REST für eine einfache Anwendung eingesetzt werden können, die über HTTP programmatisch genutzt werden kann. Dabei liegt der Fokus nicht auf inhaltlicher Vollständigkeit oder technischer Raffinesse, sondern auf der Illustration der wesentlichen Konzepte.
• In Kapitel 4: Ressourcen beschäftigen wir uns mit dem abstrakten Konzept von Ressourcen und seiner konkreten Ausprägung im WWW. Neben der Identifikation mithilfe von URIs und der Einführung von Repräsentationen finden Sie hier auch Hinweise auf ein sinnvolles und REST-konformes Ressourcen- und URI-Design.
• Kapitel 5: Verben stellt das abstrakte Konzept von Schnittstellen mit einem immer gleichen Satz von Operationen und die konkrete Ausprägung in HTTP vor. Neben den bekannten aus dem HTTP-Standard werden auch einige neuere Verben sowie die Möglichkeit zur Definition eigener Verben beschrieben.
• Das Kapitel 6: Hypermedia spielt eine zentrale Rolle für das Verständnis von REST jenseits einfacher CRUD⁷-Beispiele. Dahinter verbirgt sich das Konzept, Ressourcen miteinander zu verknüpfen, den Kontrollfluss einer Applikation dynamisch zu steuern und separat entwickelte Ressourcen unabhängig von ihrer Implem...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Inhaltsverzeichnis
• 1 Einleitung
• 2 Einführung in REST
• 3 Fallstudie: OrderManager
• 4 Ressourcen
• 5 Verben
• 6 Hypermedia
• 7 Repräsentationsformate
• 8 Fallstudie: AtomPub
• 9 Sitzungen und Skalierbarkeit
• 10 Caching
• 11 Sicherheit
• 12 Dokumentation
• 13 Erweiterte Anwendungsfälle
• 14 Fallstudie: OrderManager, Iteration 2
• 15 Architektur und Umsetzung
• 16 »Enterprise REST«: SOA auf Basis von RESTful HTTP
• 17 Weboberflächen mit ROCA
• Anhang
• Index
• Fußnoten