|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: |
Stefan Tilkov beschäftigt sich seit Beginn der 90er-Jahre mit Architekturansätzen für große, verteilte Systemlandschaften. Von 1993 bis 1998 war er in verschiedenen Rollen bei einem mittelständischen Softwarehaus tätig, zuletzt als Leiter des Bereichs Anwendungsentwicklung, bevor er 1999 die Technologieberatung innoQ Deutschland GmbH mitgründete. Als Geschäftsführer und Principal Consultant beschäftigt er sich dort schwerpunktmäßig mit leichtgewichtigen Architekturansätzen und serviceorientierten IT-Architekturen.
Martin Eigenbrodt ist seit 2009 Mitarbeiter bei innoQ. Als Senior Consultant gehört sowohl die Schulung und Beratung beim Entwurf von RESTful APIs zu seinen Aufgaben, als auch deren konkrete Implementierung. Technologisch liegt sein Schwerpunkt dabei auf Scala und Play.
Silvia Schreier beschäftigt sich seit einigen Jahren mit REST. Zunächst im Rahmen ihrer Tätigkeit als wissenschaftliche Mitarbeiterin an der FernUniversität in Hagen und seit 2013 als Consultant bei innoQ. Dort liegt ihr Schwerpunkt auf dem Entwurf und der Entwicklung REST- und ROCA-konformer Anwendungen mit verschiedensten Programmiersprachen und Persistenzlösungen. Außerdem versucht sie bei Veranstaltungen verschiedenster Initiativen andere Menschen für die IT zu begeistern.
Oliver Wolf beschäftigt sich seit vielen Jahren mit Software- und Systemarchitektur und interessiert sich besonders für große, verteilte Systeme mit hohen Anforderungen an Sicherheit, Skalierbarkeit und Flexiblität. Bevor er als Principal Consultant zu innoQ kam, war er unter anderem als Chefarchitekt, Technischer Produktmanager und Berater bei verschiedenen IT-Unternehmen tätig.
Entwicklung und Integration nach dem Architekturstil des Web
3., aktualisierte und erweiterte Auflage
Stefan Tilkov
Stefan.Tilkov@innoq.com
Martin Eigenbrodt
Martin.Eigenbrodt@innoq.com
Silvia Schreier
Silvia.Schreier@innoq.com
Oliver Wolf
Oliver.Wolf@innoq.com
Lektorat: Dr. Michael Barabas
Copy-Editing: Ursula Zimpfer, Herrenberg
Herstellung: Frank Heidt
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Buch 978-3-86490-120-1
PDF 978-3-86491-643-4
ePub 978-3-86491-644-1
3., aktualisierte und erweiterte Auflage 2015
Copyright © 2015 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Was lange währt, wird endlich gut – davon bin ich (Stefan Tilkov) in diesem Fall ganz besonders überzeugt, und der Grund hängt direkt damit zusammen, dass dies die letzte Verwendung der ersten Person Singular in diesem Buch war (von den historischen Vorbemerkungen zur ersten und zweiten Auflage abgesehen): Dank der neuen Co-Autoren Martin Eigenbrodt, Silvia Schreier und Oliver Wolf enthält diese Auflage zahlreiche Überarbeitungen, Fehlerkorrekturen und Ergänzungen.
In die aktuelle Ausgabe sind unsere Erfahrungen aus dem Einsatz von REST in einer Vielzahl unterschiedlicher Projekte eingeflossen. So haben wir das Beispiel, das wir in Kapitel 3 vorstellen und in Kapitel 14 erweitern, gründlich überarbeitet, insbesondere im Hinblick auf die uns immer wichtiger gewordenen Hypermedia-Aspekte. Bei der Neuimplementierung haben wir die Beispielanwendung außerdem von XML auf JSON umgestellt. Die wachsende Bedeutung von Hypermedia hat auch Einfluss auf die Diskussion von Formaten in Kapitel 7, die wir um diverse populäre JSON-basierte Hypermediaformate (HAL, Collection+JSON und SIREN) erweitert haben.
Das neue Kapitel 17 beschäftigt sich mit der Rolle von REST für Weboberflächen und stellt die »ROCA«, unseren favorisierten Ansatz zu deren Realisierung vor. Schließlich haben wir mehr als 130 einzelne »Issues« aus unserem Bugtracker gelöst – von den unvermeidlichen Tippfehlern über sachliche Ungereimtheiten, zahlreiche Aktualisierungen von Technologien und Produkten und diverse kleinere und größere Ergänzungen.
Eines der erklärten Ziele der ersten Auflage dieses Buches war es, von Implementierungsdetails zu abstrahieren und den Fokus auf das Kernthema REST zu legen. Unter anderem deshalb finden Sie keine Beispielimplementierungen in einer oder mehreren Programmiersprachen, und aus dem gleichen Grund habe ich auch Frameworks, Bibliotheken und Werkzeuge in den Anhang verbannt – die Technologie, die Sie zur Umsetzung Ihrer Clients und Server verwenden, sollte für keines der diskutierten Themen eine Rolle spielen.
Grundsätzlich habe ich diese Linie auch in der zweiten Auflage beibehalten. In vielen Diskussionen, die ich zusammen mit meinen Kollegen in diversen Kundenprojekten und Workshops führen konnte, wurde jedoch klar, dass sich bei der Umsetzung einer konkreten Architektur auf Basis von RESTful HTTP eine Reihe wiederkehrender, ähnlicher Fragestellungen ergeben, für die sich auch ähnliche Lösungen oder Lösungsmuster finden lassen – weitgehend unabhängig von den Details der Implementierungsplattform. REST ist nicht trivial; auch nach jahrelanger Beschäftigung mit Theorie und Praxis lernt man immer noch dazu. Häufig verschiebt sich dabei mit zunehmender Erfahrung auch das, was man für den Kern, für das wichtigste Element des Modells hält, und Dinge, die zunächst wie eine gute Idee erscheinen, stellen sich langfristig als Irrweg heraus. Das neue Kapitel 15, »Architektur und Umsetzung«, beschäftigt sich daher mit dem »Wie« und liefert einige konkrete Hilfestellungen für die praktische Umsetzung der im Buch vorgestellten Prinzipien. Aufmerksamen Lesern der ersten Auflage ist es zu verdanken, dass diverse Fehler korrigiert werden konnten.
Vor zwanzig Jahren hätte niemand das phänomenale Wachstum des World Wide Web vorhersehen können. Man kann das auf pures Glück schieben, aber eine solche Sicht ist weder richtig noch fair. Einfach gesagt ist es die Architektur des Web, die dessen Wachstum und Erfolg ermöglicht hat. Eine solche Aussage mag gewagt klingen, sehen viele in einer Softwarearchitektur doch nicht mehr als ein paar Kästchen mit Linien dazwischen, die jemand auf Präsentationsfolien gezeichnet hat. Zwar können solche Diagramme zur Darstellung von Systemkomponenten und ihren Beziehungen nützlich sein, aber sie allein repräsentieren eine tatsächliche Softwarearchitektur weder vollständig noch ausreichend. Ich habe viele Jahre lang das Wort »Architekt« als Teil meiner Berufsbezeichnung benutzt, mich aber vor ungefähr fünf Jahren davon verabschiedet. Ein Grund dafür war, dass der Begriff »Architekt« mehr und mehr eine Trennung vom tatsächlichen System und dessen Code implizierte; viele selbsternannte Architekten sind in der Tat von der täglichen Arbeit des Erstellens und des Wartens von Software recht weit entfernt. Glücklicherweise trifft das auf mich nicht zu. Der Begriff legt auch eine Trennung von Architekten und Entwicklern nahe, mit der Idee, dass Architekten ein System definieren und die Regeln durchsetzen, während Entwickler das System einfach stupide anhand von Anweisungen umsetzen, die sie von den Architekten erhalten haben – was natürlich völliger Unsinn ist. Aber der wichtigste Grund, aus dem ich mich nicht mehr »Softwarearchitekt« nenne, ist folgender: In den Jahren, in denen ich diesen Titel benutzt habe, habe ich gelernt, dass gute Architekturen keine Regelpolizei benötigen. Stattdessen überwachen sich gute Architekturen praktisch selbst, indem sie klare Konzepte und Grenzen für diejenigen vorgeben, die damit arbeiten. Bei Architekturen geht es um Systemziele und erwünschte Systemeigenschaften, um eine gemeinsame Terminologie und um Kommunikation. Architekturen geben Grenzen, Richtlinien, Einschränkungen und Regeln vor. Eine Architektur zu definieren bedeutet zu entscheiden, welche Eigenschaften das System haben soll, und eine Reihe von Einschränkungen vorzugeben, mit denen diese Eigenschaften erreicht werden können. Korrekt definiert können Eigenschaften und Einschränkungen als Wegweiser für diejenigen dienen, die ein System erstellen, das der Architektur folgen soll, selbst wenn kein direkter Kontakt zu den Urhebern dieser Architektur mehr besteht. Hätte die Webarchitektur diese Eigenschaft nicht, mit anderen Worten: Würde sie die dezentrale, unabhängige Entwicklung nicht ermöglichen – dann könnten nur einige wenige sie verstehen, und ihr spektakuläres Wachstum wäre niemals möglich gewesen. Die Architektur des Web setzt den Architekturstil »Representational State Transfer« (REST) um. Wie Sie in diesem Buch lernen werden, ist bei REST, mehr als bei jeder anderen Architektur und jedem anderen Architekturstil, sehr klar definiert, was die erwünschten Eigenschaften sind und an welche Einschränkungen man sich halten muss, um sie zu erreichen. Bei REST werden sonst vage Begriffe wie »Skalierbarkeit« oder »lose Kopplung« dank der Einschränkungen und der damit verbundenen Kompromisse auf einmal fast offensichtlich. Anstatt Sie mit einem Haufen von Kästchen und Pfeilen zu versorgen, liefert REST Ihnen eine Reihe von Entwurfsentscheidungen und Einschränkungen, die Sie ähnlich wie einen Satz von Kontrollreglern einstellen können, um zu sehen, wie sich dies auf die Systemeigenschaften auswirkt. Anstatt eines weiteren Silos starrer Entwurfsmuster, durch das Sie sich am Ende mit mehr Integrationsproblemen als vorher wiederfinden, ist REST vielleicht ironischerweise in seinen Einschränkungen flexibel. Es erlaubt Ihnen, geeignete Kompromisse für Ihr spezifisches System zu machen und es dennoch in die Gesamtarchitektur einzufügen. Dieser Grad von Anpassbarkeit und Skalierbarkeit ist ein herausragendes Merkmal von REST. So können Sie mit der HTTP-Manifestation des Architekturstils kleine und einfache Systeme verteilter Dienste erstellen und sie dennoch mit ultragroßen weltweit verteilten Systemen wie dem Web integrieren, da beide Enden des Spektrums auf dem gleichen Satz von Prinzipien und Einschränkungen aufbauen. REST ist nicht schwer zu verstehen, aber es hat Tiefe, und es dauert eine gewisse Zeit, bis man es vollständig versteht. Es ist daher wichtig, dass Sie REST nicht von jemandem lernen, der einfach nur Roy Fieldings geniale Doktorarbeit [rest], durch die es definiert wurde, nacherzählt, sondern von jemandem, der mit REST gearbeitet und es durch die praktische Anwendung kennengelernt hat. Stefan Tilkov ist einer der wenigen, die sowohl lehren als auch tun können; er hat REST praktisch eingesetzt, hat eine Reihe von exzellenten und nützlichen Artikeln darüber geschrieben und eine Reihe von Präsentationen dazu gehalten. Ich kenne ihn seit mehreren Jahren und hatte nicht nur das Glück, REST mit ihm bei diversen Gelegenheiten sowohl per E-Mail als auch persönlich diskutieren zu können, sondern auch sein Feedback zu meinen eigenen Publikationen zu REST zu bekommen. Ich kann ehrlich sagen, dass er einer der wenigen mit sowohl genügender Erfahrung als auch der richtigen Balance zwischen »Lehren« und »Tun« ist, die benötigt wird, um Sie zum richtigen Verständnis von REST zu führen. Ich überlasse Sie daher seinen fähigen Händen im Vertrauen, dass Sie sein Wissen und seine Führung genau so nützlich finden werden, wie ich es getan habe.
Steve Vinoski
Chelmsford, MA USA Mai 2009
Die Konzepte, Ideen und Entwurfsmuster in diesem Buch sind das Ergebnis vieler Diskussionen mit den Mitgliedern der internationalen, informellen REST-Community – persönlich, per E-Mail und über diverse Blogbeiträge. Viele Gedanken sind daher stark beeinflusst von Jan Algermissen, Subbu Allamaraju, Mark Baker, Benjamin Carlyle, Duncan Cragg, Alan Dean, Dan Diephouse, Paul Downey, Nick Gall, Joe Gregorio, Marc Hadley, Bill de hÓra, Peter Lacey, Mark Nottingham, Dave Orchard, Aristoteles Pagaltzis, Mark Pilgrim, Paul Prescod, Ian Robinson, Leonard Richardson, Paul Sandoz, Ryan Tomayko, Steve Vinoski, Jim Webber und natürlich Roy T. Fielding.
Wir danken Till Schulte-Coerne und Falk Hoppe, ohne die es das Kapitel zu ROCA nicht gäbe. Sie würden ein deutlich schlechteres Buch in der Hand halten, wenn wir nicht wertvolle Kommentare und Korrekturen zum Manuskript von Jan Algermissen, Thomas Bandholtz, Stefan Bodewig, Javier Botana, Vladimir Dobriakov, Frederik Dohr, Phillip Ghadir, Prof. Dominik Gruntz, Rainer Jaspert, André Kemper, Willem van Kerkhof, Holger Kraus, Michael Krauße, Diego Künzi, Arne Landwehr, Tammo van Lessen, Dirk Lingstädt, Dr. Daniel Luebke, Christian Oberschulte, Aristoteles Pagaltzis, Rubén Parés-Selders, Marc Schlienger und Till Schulte-Coerne erhalten hätten. An den verbleibenden Fehlern tragen wir allein die Schuld.
Stefan
Den größten Beitrag zum Buch hat jedoch meine Familie geleistet – Melanie, Jonas und Mia –, die an so manchem Abend und an diversen Wochenenden auf mich verzichten musste. Danke!
Martin
Auch für mich wäre die Arbeit an diesem Buch nicht möglich gewesen ohne die Hilfe meiner Familie. Anja, Nina und Lisa – ich danke Euch für euer liebevolles Verständnis und all die Zeit, die auch Ihr investiert habt.
Silvia
Mein Dank gilt Christian, der immer für mich da ist, sowie meinen Eltern, Regine und Karl-Heinz, und meiner Schwester Juliane für ihre Unterstützung.
Oliver
Ich danke Carmen, die von der wenigen Zeit, die wir gemeinsam verbringen können, noch einmal ein gutes Stück abgegeben hat.
Stefan Tilkov, Martin Eigenbrodt, Silvia Schreier, Oliver Wolf
Januar 2015
1 Einleitung
1.1 Warum REST?
1.1.1 Lose Kopplung
1.1.2 Interoperabilität
1.1.3 Wiederverwendung
1.1.4 Performance und Skalierbarkeit
1.2 Zielgruppe und Voraussetzungen
1.3 Zur Struktur des Buches
2 Einführung in REST
2.1 Eine kurze Geschichte von REST
2.2 Grundprinzipien
2.3 Zusammenfassung
3 Fallstudie: OrderManager
3.1 Fachlicher Hintergrund
3.2 Ressourcen
3.2.1 Bestellungen
3.2.2 Bestellungen in unterschiedlichen Zuständen
3.2.3 Stornierungen
3.3 Repräsentationen
3.4 Zusammenfassung
4 Ressourcen
4.1 Ressourcen und Repräsentationen
4.2 Ressourcendesign
4.2.1 Primärressourcen
4.2.2 Subressourcen
4.2.3 Listen
4.2.4 Projektionen
4.2.5 Aggregationen
4.2.6 Aktivitäten
4.2.7 Konzept- und Informationsressourcen
4.2.8 Evolutionäre Weiterentwicklung und YAGNI
4.3 Ressourcenidentifikation und URIs
4.3.1 URI, IRI, URL, URN, XRI?
4.3.2 Anatomie einer HTTP-URI
4.3.3 URI-Templates
4.4 URI-Design
4.4.1 URI-Entwurfsgrundsätze
4.4.2 REST aus Versehen
4.4.3 Stabile URIs
4.5 Zusammenfassung
5 Verben
5.1 Standardverben von HTTP 1.1
5.1.1 GET
5.1.2 HEAD
5.1.3 PUT
5.1.4 POST
5.1.5 DELETE
5.1.6 OPTIONS
5.1.7 TRACE und CONNECT
5.2 HTTP-Verben in der Praxis
5.3 Tricks für PUT und DELETE
5.3.1 HTML-Formulare
5.3.2 Firewalls und eingeschränkte Clients
5.4 Definition eigener Methoden
5.4.1 WebDAV
5.4.2 Partial Updates und PATCH
5.4.3 Multi-Request-Verarbeitung
5.5 LINK und UNLINK
5.6 Zusammenfassung
6 Hypermedia
6.1 Hypermedia im Browser
6.2 HATEOAS und das »Human Web«
6.3 Hypermedia in der Anwendung-zu-Anwendung-Kommunikation
6.4 Ressourcenverknüpfung
6.5 Einstiegspunkte
6.6 Aktionsrelationen
6.7 Darstellung von Links und das <link>-Element
6.8 Standardisierung von Link-Relationen
6.9 Zusammenfassung
7 Repräsentationsformate
7.1 Formate, Medientypen und Content Negotiation
7.2 JSON
7.2.1 HAL
7.2.2 Collection+JSON
7.2.3 SIREN
7.2.4 Fazit
7.3 XML
7.4 HTML/XHTML
7.5 Textformate
7.5.1 Plaintext
7.5.2 URI-Listen
7.6 CSV
7.7 RSS und Atom
7.8 Binäre Formate
7.9 Microformats
7.10 RDF
7.11 Zusammenfassung
8 Fallstudie: AtomPub
8.1 Historie
8.2 Discovery und Metadaten
8.3 Ressourcentypen
8.4 REST und Atom/AtomPub
8.5 Zusammenfassung
9 Sitzungen und Skalierbarkeit
9.1 Cookies
9.2 Ressourcen- und Clientstatus
9.3 Skalierbarkeit und »Shared Nothing«-Architektur
9.4 Zusammenfassung
10 Caching
10.1 Expirationsmodell
10.2 Validierungsmodell
10.3 Cache-Topologien
10.4 Caching und Header
10.4.1 Response-Header
10.4.2 Request-Header
10.5 Schwache ETags
10.6 Invalidierung
10.7 Caching und personalisierte Inhalte
10.8 Caching im Internet
10.9 Zusammenfassung
11 Sicherheit
11.1 SSL und HTTPS
11.2 Authentisierung, Authentifizierung, Autorisierung
11.3 HTTP-Authentifizierung
11.4 HTTP Basic Authentication
11.5 Der 80%-Fall: HTTPS + Basic-Auth
11.6 HTTP Digest Authentication
11.7 Browser-Integration und Cookies
11.8 HMAC
11.9 OpenID
11.10 OAuth
11.10.1 OAuth 1.0
11.10.2 OAuth 2.0
11.11 Autorisierung
11.12 Nachrichtenverschlüsselung und Signatur
11.13 Zusammenfassung
12 Dokumentation
12.1 Selbstbeschreibende Nachrichten
12.2 Hypermedia
12.3 HTML als Standardformat
12.4 Beschreibungsformate
12.4.1 WSDL
12.4.2 WADL
12.4.3 Swagger, RAML und API Blueprint
12.4.4 RDDL
12.5 Zusammenfassung
13 Erweiterte Anwendungsfälle
13.1 Asynchrone Verarbeitung
13.1.1 Notifikation per HTTP-»Callback«
13.1.2 Polling
13.2 Zuverlässigkeit
13.2.1 PUT statt POST
13.2.2 POST-PUT-Kombination
13.2.3 Reliable POST
13.3 Transaktionen
13.3.1 Atomare (Datenbank-)Transaktionen
13.3.2 Verteilte Transaktionen
13.3.3 Fachliche Transaktionen
13.4 Parallelzugriff und konditionale Verarbeitung
13.5 Versionierung
13.5.1 Zusätzliche Ressourcen
13.5.2 Erweiterbare Datenformate
13.5.3 Versionsabhängige Repräsentationen
13.6 Zusammenfassung
14 Fallstudie: OrderManager, Iteration 2
14.1 OrderEntry
14.1.1 Medientypen
14.1.2 Servicedokumentation
14.1.3 Bestellpositionen
14.1.4 Zustandsänderungen
14.2 Fulfilment
14.2.1 Notifikation über neue Bestellungen
14.2.2 Bestellübernahme
14.2.3 Produktionsaufträge
14.2.4 Versandfristen
14.2.5 Lieferdatum
14.3 Reporting
14.4 Zusammenfassung
15 Architektur und Umsetzung
15.1 Architekturebenen
15.2 Domänenarchitektur
15.2.1 Systemgrenzen und Ressourcen
15.2.2 Medientypen und Kontrakte
15.2.3 Identität und Adressierbarkeit
15.3 Softwarearchitektur
15.3.1 Schichten
15.3.2 Domänenmodell
15.3.3 Nutzung von Diensten
15.4 Systemarchitektur
15.4.1 Netztopologie
15.4.2 Caching
15.4.3 Firewalls
15.5 Frontend-Architektur
15.5.1 Benutzerschnittstellen und RESTful-HTTP-Backends
15.5.2 Sinn und Unsinn von Portalen
15.6 Web-API-Architektur
15.7 Zusammenfassung
16 »Enterprise REST«: SOA auf Basis von RESTful HTTP
16.1 SOA-Definitionen
16.2 Business/IT-Alignment
16.3 Governance
16.3.1 Daten- und Schnittstellenbeschreibungen
16.3.2 Registry/Repository-Lösungen
16.3.3 Discovery
16.4 Orchestrierung und Choreografie
16.5 Enterprise Service Bus (ESB)
16.6 WSDL, SOAP & WS-*: WS-Architektur
16.7 Zusammenfassung
17 Weboberflächen mit ROCA
17.1 REST: Nicht nur für Webservices
17.2 Clientaspekte von ROCA
17.2.1 Semantisches HTML
17.2.2 CSS
17.2.3 Die Rolle von JavaScript
17.2.4 Unobtrusive JavaScript und Progressive Enhancement
17.3 ROCA vs. Single Page Apps
17.4 Zusammenfassung
Anhang
A HTTP-Statuscodes
B Fortgeschrittene HTTP-Mechanismen
B.1 Persistente Verbindungen
B.2 Request-Pipelining
B.3 Range Requests
B.4 Chunked Encoding
C Werkzeuge und Bibliotheken
C.1 Kommandozeilen-Clients
C.2 HTTP-Server
C.3 Caches
C.4 Programmierumgebungen
C.4.1 Java/JVM-Sprachen
C.4.2 Microsoft .NET
C.4.3 Ruby
C.4.4 Python, Perl, Node.js & Co
D HTTP/2 und SPDY
D.1 Geschichte von HTTP
D.2 SPDY
D.3 HTTP/2
Referenzen
Index
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?
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.
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.
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.
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).
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.
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önnen5.
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 Werkzeuge6.
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 CRUD7-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 Implementierungsstrategie oder ihrer Lokation zu kombinieren.
Kapitel 7: Repräsentationsformate beschäftigt sich mit den Datenformaten, die in REST/HTTP-Anwendungen in der Regel zum Einsatz kommen. Dabei werden die Vor- und Nachteile verschiedener Formate diskutiert und Hinweise zu deren Anwendung geliefert. Neben traditionellen Formaten betrachten wir auch einige, bei deren Design Hypermedia explizit berücksichtigt wurde.
In Kapitel 8: Fallstudie: AtomPub finden Sie eine Beschreibung eines REST-konformen Protokolls zur Manipulation von Inhalten wie z. B. Einträgen in Weblogs oder Artikeln in einem CMS-System. Das Atom Publishing Protocol (AtomPub) ist ein offizieller Standard, der unter Beteiligung diverser Webexperten und REST-Verfechter definiert wurde und daher in vielerlei Hinsicht der Musterknabe der REST-Familie ist.
In Kapitel 9: Sitzungen und Skalierbarkeit erfahren Sie mehr über den Zusammenhang zwischen der Skalierbarkeit eines Systems und der Rolle, die der Verzicht auf eine sitzungsbehaftete Kommunikation dafür spielt. Thema sind neben der Motivation auch Empfehlungen, wie Sie einen sessionorientierten in einen sessionfreien Entwurf überführen können.
Kapitel 10: Caching beschäftigt sich mit der wichtigsten Performance-Optimierung im WWW und zeigt, wie Sie die beiden unterschiedlichen dafür vom HTTP-Protokoll unterstützten Verfahren – Validierungs- und Expirationsmodell – für Geschäftsanwendungen mit einer REST-Architektur nutzen können.
Kapitel 11: Sicherheit gibt einen kurzen Abriss über die wesentlichen Sicherheitskonzepte im REST/HTTP-Umfeld und stellt neben allgemeinen Konzepten und den in HTTP integrierten Authentifizierungsmechanismen verschiedene Standards wie SSL, OpenID und OAuth vor.
Das Kapitel 12: Dokumentation beschäftigt sich mit Strategien zur Dokumentation von REST-Anwendungen, sowohl auf Basis einfacher HTML-Seiten wie auch mithilfe von standardisierten Beschreibungssprachen wie WSDL, RDDL oder WADL oder neuerer Ansätze wie Swagger, RAML oder API Blueprint.
Thema von Kapitel 13: Erweiterte Anwendungsfälle sind asynchrone Verarbeitung, zuverlässige Zustellung, Transaktionen und die Konflikterkennung bei parallelen Zugriffen.
In Kapitel 14: Fallstudie: OrderManager, Iteration 2 erweitern wir unser Beispiel aus Kapitel 3 sowohl fachlich als auch technisch mithilfe des Wissens aus den Kapiteln 4 – 13, um Ihnen einen realistischen Eindruck von den typischen Entwurfsentscheidungen bei einer nicht trivialen REST-Anwendung zu geben.
Kapitel 15: Architektur und Umsetzung befasst sich mit den Auswirkungen, die sich aus dem Einsatz von REST und HTTP für unterschiedliche Architekturaspekte ergeben. Dazu zählen die Anwendungs- und Systemarchitektur, die Architektur von Benutzerschnittstellen, die interne Softwarearchitektur einzelner Systeme und die neuen Herausforderungen bei der Gestaltung von Web-APIs.
Kapitel 16: »Enterprise REST«: SOA auf Basis von RESTful HTTP setzt die Konzepte von REST und die Technologien des Web in Beziehung zu serviceorientierten Architekturen (SOA) und zeigt, wie diese beiden Ansätze zusammenpassen können. Darüber hinaus finden Sie hier eine Diskussion über die Vor- und Nachteile von Webservices auf Basis von WSDL, SOAP und WS-* im Vergleich zu REST und HTTP.
Kapitel 17: Weboberflächen mit ROCA beschäftigt sich mit Webanwendungen, also REST/HTTP-Anwendungen, bei denen der Client ein Webbrowser ist, den ein Mensch verwendet. Wir diskutieren, wie man auch in diesem Fall das Beste aus dem Web herausholen kann. Neben REST stehen hier semantisches HTML, CSS und JavaScript sowie die klare Trennung von Verantwortlichkeiten im Vordergrund.
Im Anhang schließlich erfahren Sie mehr über die Werkzeuge, die Ihnen für eine konkrete Umsetzung einer REST/HTTP-basierten Lösung zur Verfügung stehen, und finden eine Übersicht der HTTP-Statuscodes, eine Beschreibung einiger fortgeschrittener HTTP-Mechanismen wie Pipelining und persistente Sessions, einen Verweis auf diverse Onlineressourcen mit weiterführenden Informationen, einen Überblick zu der Entwicklungen von HTTP/2, eine Liste der Referenzen sowie den Index.
Ergänzungen und Errata sowie diverse Onlineressourcen finden Sie auf der Website zum Buch, http://rest-http.info.
REST ist mittlerweile im »Mainstream« angekommen, und tatsächlich haben die unter diesem Namen zusammengefassten Konzepte das WWW, das wir heute kennen, schon vor der aktuellen Popularität bereits über lange Jahre geprägt. In diesem Kapitel werden wir uns daher zunächst mit der Geschichte von REST beschäftigen und danach die wichtigsten Grundprinzipien erläutern.
Die Anfänge des Web in den frühen 90er-Jahren waren von einer sehr einfachen Metapher geprägt: Dokumente in einem Standardformat, die über eine eindeutige Identifikation verfügten und sich darüber gegenseitig referenzieren konnten, sowie ein einfaches Protokoll, um diese Dokumente zu übertragen. Schon bald jedoch wurde das Web mit dynamischen Informationen angereichert, die auf Datenbankinhalten oder mehr oder weniger komplexen Berechnungen beruhten.
Daraus resultierte eine Unklarheit in der Bedeutung der einzelnen Konzepte des WWW. Identifiziert eine URI ein bestimmtes Dokument oder einen Dienst, der viele Dokumente (oder allgemeiner: Informationen) liefern kann? Wie passt die Metapher eines Dokumentes, das transferiert wird, zu einem Dienst, der sein Ergebnis auf Basis einer komplexen Implementierung ermittelt? Dem Web in der Praxis fehlte eine zugrunde liegende Theorie, ein konzeptionelles Modell mit klaren Begriffen, mit dessen Hilfe man über das Pro und Contra von möglichen Weiterentwicklungen diskutieren konnte. Mit anderen Worten: Dem Web fehlte ein theoretisches Fundament – eine formale Architektur.
Fielding, der seit Beginn (ca. 1994) in die Standardisierung der Webprotokolle involviert war, konstruierte deshalb ein Konzept, das initial den Namen »HTTP Object Model« trug. Während der Standardisierung von HTTP 1.0, vor allem aber während der Weiterentwicklung zu HTTP 1.1 nutzte er dieses Modell zum einen als Rahmen für das Design von HTTP und passte es zum anderen an, wenn es einer sinnvollen Veränderung im Weg stand.
Im Kern dieses Modells steht die Idee, für statische Inhalte und dynamisch berechnete Informationen, die ein globales, gigantisches Informationssystem bilden, ein einheitliches Konzept zu definieren – eine Idee, mit dem wir uns in den weiteren Kapiteln detailliert beschäftigen werden.
In seiner Dissertation, die er im Jahr 2000 beendete, abstrahierte Fielding von der konkreten Architektur, die HTTP zugrunde liegt, und legte den Schwerpunkt auf die Konzepte anstatt auf die konkrete Syntax, die Details des Protokolldesigns und die vielen Kompromisse, die aus Kompatibilitätsgründen eingegangen werden mussten. Als Ergebnis entstand der Architekturstil1 REST. Dieser ist somit eine Stufe abstrakter als die HTTP-Architektur: Theoretisch könnte man die Prinzipien von REST auch mit einem neu erfundenen Satz von Protokollen umsetzen. In der Praxis ist jedoch tatsächlich nur das Web als konkrete Ausprägung des Architekturstils relevant.
HTTP, URIs und die anderen Standards des Web lassen sich auf unterschiedliche Arten verwenden. Idealerweise setzt man eine Technologie so ein, wie es sich deren Architekt vorgestellt hat, denn dadurch ist die Wahrscheinlichkeit am höchsten, dass man auch die Vorteile optimal nutzt. Aber natürlich kann man auch gegen die Regeln verstoßen, und in der Praxis kommt das sehr häufig vor: Viele der Frameworks, Bibliotheken und öffentlichen Web-APIs sind alles andere als »RESTful«, auch wenn dies häufig behauptet wird.
Das Paradebeispiel für eine Verwendung der Protokolle des WWW ohne den Einsatz der entsprechenden Architektur sind Webservices auf Basis von SOAP und WSDL. Diese verwenden zwar HTTP, aber eines der Kernkonzepte besteht in der sogenannten »Transportunabhängigkeit«: HTTP ist nur einer von vielen Mechanismen, über den Daten von A nach B übertragen werden können.2345
