REST und HTTP E-Book

Stefan Tilkov

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2015

Seitenzahl: 431

Beschreibung

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.

Leseprobe

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+:www.dpunkt.de/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.

REST und HTTP

Entwicklung und Integration nach dem Architekturstil des Web

3., aktualisierte und erweiterte Auflage

Stefan TilkovMartin EigenbrodtSilvia SchreierOliver Wolf

Stefan [email protected]

Martin [email protected]

Silvia [email protected]

Oliver [email protected]

Lektorat: Dr. Michael BarabasCopy-Editing: Ursula Zimpfer, HerrenbergHerstellung: Frank HeidtUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen NationalbibliothekDie 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-1PDF    978-3-86491-643-4ePub    978-3-86491-644-1

3., aktualisierte und erweiterte Auflage 2015Copyright © 2015 dpunkt.verlag GmbHWieblinger Weg 1769123 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

Vorbemerkung zur dritten Auflage

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.

Vorbemerkung zur zweiten Auflage

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.

Vorwort zur ersten Auflage

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

Danksagung

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

Inhaltsverzeichnis

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

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 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.

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 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.

2 Einführung in REST

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.

2.1 Eine kurze Geschichte von REST

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.2 Aus diesem Grund gab es in den vergangenen Jahren immer wieder Debatten darüber, ob nun SOAP oder REST die bessere Lösung sei3. Lange Zeit war REST dabei nur der Favorit einer kleinen Minderheit; eine zunehmende Frustration mit dem Webservices-Technologiestack und eine immer stärkere Verbreitung von Web-APIs ohne SOAP4 haben jedoch mittlerweile zu einem großen Interesse an REST im Service-Umfeld geführt. In vielen Fällen wird REST dabei ohne größere Debatte als die »richtige« Lösung vorausgesetzt.5

Aber auch ganz ohne Webservices kann man mehr oder weniger katastrophal gegen die Grundregeln von REST verstoßen, sehr gut zu sehen an Webframeworks bzw. damit erstellten Anwendungen, die sich nicht wie Webanwendungen anfühlen, nicht so entwickelt werden und auch keinen der Vorteile des Web ausnutzen. Während sich Benutzer mit defekten Back- und Forward-Schaltflächen, ablaufenden Sitzungen, schlechten Antwortzeiten und nicht verlinkbaren Informationen herumplagen, ist auch aus Architektursicht hier weder von REST noch von RESTful HTTP etwas zu sehen.

Eine kurze Anmerkung zu Unterscheidung »REST« und »RESTful HTTP«: Im Kontext dieses Buches verwenden wir den Begriff REST formal gesehen nicht immer korrekt. Genau genommen müssten wir konsequent unterscheiden zwischen dem abstrakten Architekturstil REST, der konkreten, weitgehend REST-konformen Implementierung HTTP und einzelnen Webanwendungen und Diensten, die mehr oder weniger konform zu den REST-Prinzipien umgesetzt sein können. Wir folgen jedoch stattdessen dem allgemeinen Sprachgebrauch und benutzen »REST« und »REST-konforme HTTP-Nutzung« (englisch »RESTful HTTP«) in den meisten Fällen synonym6.

2.2 Grundprinzipien

Wenn wir REST auf ein Minimum reduzieren, ergeben sich fünf Kernprinzipien, die wir wie folgt zusammenfassen können:

Ressourcen mit eindeutiger Identifikation

Verknüpfungen/Hypermedia

Standardmethoden

Unterschiedliche Repräsentationen

Statuslose Kommunikation

Schauen wir uns diese Prinzipien näher an.

Eindeutige Identifikation

Wenn Sie sich an das letzte System erinnern, das Sie entwickelt haben, so gab es sicherlich eine Menge von Kernabstraktionen, deren Instanzen es verdient hätten, eindeutig identifiziert zu werden. Im Web gibt es ein einheitliches Konzept für die Vergabe von IDs – nämlich die URI. URIs bilden einen globalen Namensraum, und die Verwendung einer URI als ID stellt sicher, dass Sie die wesentlichen Elemente weltweit eindeutig identifizieren können.

Der wesentliche Vorteil eines konsistenten Schemas für Namen ist, dass Sie kein eigenes mehr erfinden müssen – Sie können sich auf das bereits bestehende verlassen, das, wie man kaum bestreiten kann, sehr gut funktioniert, hervorragend skaliert und von wirklich jedem verstanden wird. Wenn Sie an ein zufällig ausgewähltes Geschäftsobjekt aus Ihrer letzten Anwendung denken, können Sie wahrscheinlich leicht einen Fall konstruieren, in dem die Identifikation über URIs nützlich gewesen wäre. Hat Ihre Anwendung zum Beispiel eine Abstraktion »Kunde« enthalten, wären Ihre Anwender wahrscheinlich gern in der Lage gewesen, einem Kollegen einen Link auf einen bestimmten Kunden zu schicken, sich ein Lesezeichen zu setzen oder die ID (die URI) des Kunden einfach nur auf einem Stück Papier zu notieren. Und stellen Sie sich vor, wie viel Geschäft ein Onlineunternehmen wie Amazon.com nicht machen würde, wenn man keinen Link auf jedes einzelne Produkt verschicken könnte!

Wird man zum ersten Mal mit dieser Idee konfrontiert, fragt man sich, ob man nun jeden einzelnen Datenbankeintrag (und dessen ID) exponieren sollte – und schaudert beim bloßen Gedanken. Schließlich haben uns Jahre der Objektorientierung gelehrt, dass wir Implementationsdetails verbergen sollten. Aber dies ist nur ein scheinbarer Konflikt: Die Dinge (Ressourcen), die Sie nach außen bekannt geben, befinden sich auf einem anderen Abstraktionsniveau als die einzelnen Datenelemente. Ein Beispiel: Man würde in einem Bestellsystem vielleicht eine Ressource »Order« exponieren und ihr eine URI spendieren, nicht jedoch jeder einzelnen Bestellposition oder der Liefer- und Rechnungsadresse7. Treibt man das Prinzip, alle sinnvollen Dinge zu identifizieren, konsequent weiter, so ergeben sich auf einmal neue Ressourcen, an die man normalerweise nicht gedacht hätte – ein Prozess oder Prozessschritt, ein Verkauf, eine Verhandlung, eine Angebotsanfrage – alles Beispiele für Ressourcen, die es zu identifizieren lohnt. Dies wiederum kann dann dazu führen, dass es mehr persistente Entitäten gibt als in einem Nicht-REST-Design.

Im Folgenden einige Beispiel-URIs:

http://example.com/customers/1234

http://example.com/orders/2007/10/776654

http://example.com/products/

http://example.com/processes/salary-increase-234

Da wir menschenlesbare URIs verwendet haben – eine sinnvolle, wenn auch aus REST-Sicht völlig irrelevante Entscheidung –, sollten sie relativ leicht zu interpretieren sein. Die Vorteile des einheitlichen, global gültigen Namensschemas gelten sowohl für die browserbasierte als auch für die Anwendung-zu-Anwendung-Kommunikation.

Fassen wir das erste Prinzip noch einmal zusammen: Verwenden Sie URIs, um alle die Instanzen aller wesentlichen Abstraktionen Ihrer Anwendung zu identifizieren, die es Wert sind – unabhängig davon, ob es sich um individuelle Einträge oder Mengen handelt.

Hypermedia

Das nächste Prinzip hat die formale Beschreibung »Hypermedia as the engine of application state«. Im Kern verbirgt sich dahinter das Konzept von Verknüpfungen (Links). Diese sind uns allen aus HTML bekannt, aber in keiner Weise auf menschliche Nutzer beschränkt. Am besten verdeutlicht dies ein Beispiel:

{    "amount": 23,    "customer": {        "href": "http://example.com/customers/1234"    },    "product": {        "href": "http://example.com/products/4554"    },    "cancel": {        "href": "./cancellations"    }}

Wenn Sie sich die Produkt- und Kundenverknüpfungen in diesem Beispiel ansehen, können Sie sich leicht vorstellen, dass eine Applikation diesen Links »folgt«, um an weitere Informationen zu gelangen. Das wäre natürlich genauso gut denkbar, wenn nur ein einfaches ID-Attribut z. B. mit einem Integerschlüssel belegt wäre – allerdings nur im Kontext dieser einen Anwendung. Das Wunderbare am Hypermedia-Ansatz des Web ist, dass Verknüpfungen anwendungsübergreifend funktionieren – es kann sich eine andere Anwendung, ein anderer Server oder ein anderes Unternehmen auf einem anderen Kontinent dahinter verbergen, ohne dass sich der Konsument dafür interessieren muss. Weil das Namensschema global ist, können alle Ressourcen, aus denen das Web besteht, miteinander verknüpft werden.8

Wichtiger noch als die Verknüpfung zwischen Daten ist die Steuerung des Applikationszustands über Hypermedia: Ein Server kann dem Client über Hypermedia-Elemente wie z. B. Links mitteilen, welche Aktionen er als Nächstes ausführen kann. Abstrakt formuliert: Die Applikation wird damit von einem Zustand in den nächsten überführt, indem der Client einem Link folgt.

Ein Beispiel: Unsere Bestellung enthält einen Link, der eine Verknüpfung kapselt, die der Client zum Stornieren der Bestellung verwenden kann. Ist dies im aktuellen Status der Bestellung nicht mehr möglich, enthält die Bestellung diesen Link nicht mehr: Welche Statusübergänge zu einem beliebigen Zeitpunkt möglich sind, wird also durch Hypermedia gesteuert.

Aber nicht nur Links sind Hypermedia-Elemente. Diese sind nur ein Weg für einen Client, auf Basis von Informationen, die vom Server bereitgestellt werden, herauszufinden, wie ein nächster Request konstruiert werden kann. Aus dem HTML-Umfeld bestens bekannt sind Formulare, HTML-Forms. Im Gegensatz zu Links, die ein explizites Ziel haben, also auf eine bestimmte Ressource verweisen, enthalten Formulare die Regeln, nach denen einer von potenziell beliebig vielen neuen Requests erzeugt werden kann. Das folgende Beispiel illustriert das an einer Kombination verschiedener Formularelemente:

<form action="/reports" method="GET">  <select name="month">    <option value="01">01</option>    <option value="02">02</option>    ...    <option value="12">12</option>  </select>  <input type="number" name="year">  <select name="state">    <option></option>    <option value="cancelled">cancelled</option>    <option value="commited">commited</option>    <option value="created">created</option>    <option value="failed">failed</option>    <option value="processing">processing</option>    <option value="shipped">shipped</option>  </select>  <input type="submit" value="get report"/></form>

Die Menge an Kombinationsmöglichkeiten aus den beiden Select-Auswahlfeldern und dem Eingabefeld ist unendlich. Für den Client ist damit nur vorgegeben, wie er einen POST-Request konstruieren kann. Der Server ist dafür zuständig, diesen dann zu interpretieren und entweder mit einer direkten Antwort oder mit einer Weiterleitung auf eine andere, dem Client vorher unbekannte Ressource zu beantworten. Der Server steuert den Client höchst dynamisch über die Hypermedia-Elemente, die er in seine Antworten einbettet.

Zusammenfassung: Verwenden Sie Hypermedia, um Beziehungen zwischen Ressourcen herzustellen, wo immer es möglich ist, und steuern Sie den Applikationsfluss darüber. Hypermedia-Controls sind es, die das Web erst zum Web machen.

Standardmethoden

Bei der Diskussion der ersten beiden Prinzipien haben wir eine implizite Annahme unerwähnt gelassen, nämlich die Tatsache, dass eine nutzende Anwendung mit den URIs bzw. den Ressourcen, die durch sie identifiziert werden, tatsächlich etwas anfangen kann. Wenn Sie eine URI auf der Werbefläche eines Busses sehen und diese in die Adresszeile Ihres Browsers eintippen – woher weiß dieser, was er mit der URI tun kann?

Er weiß, was er damit tun kann, weil jede Ressource die gleiche Schnittstelle unterstützt, den gleichen Satz von Methoden9. Bei HTTP zählen zu diesen Methoden – zusätzlich zu den beiden, die jeder kennt (GET und POST) – auch PUT, DELETE, HEAD und OPTIONS. Die Bedeutung dieser Methoden oder »Verben« ist in der HTTP-Spezifikation beschrieben, inklusive einiger Garantien über ihr Verhalten. Als Analogie könnte man die HTTP-Schnittstelle mit einem Java-Interface vergleichen, das von jeder Ressource implementiert wird (in Pseudosyntax):

interface Resource {  Resource(URI u);  Response options();  Response get();  Response post(Request r);  Response put(Request r);  Response delete();}

Listing 2–1 Pseudocode für das REST-Interface

Da für jede Ressource das gleiche Interface verwendet wird, können Sie mit Recht erwarten, dass Sie eine Repräsentation, eine Darstellung der Ressource, mit der GET-Methode abholen können. Da die Semantik von GET in der HTTP-Spezifikation beschrieben ist, können Sie sich darauf verlassen, dass Sie damit keine Verpflichtungen eingehen: Die Methode ist »safe« (sicher). Da GET ein sehr effizientes und raffiniertes Caching unterstützt, muss der Request in vielen Fällen gar nicht zum Server geschickt werden. Sie können sich ebenfalls darauf verlassen, dass die Methode GET idempotent ist. Das bedeutet, dass Sie im Fall einer ausbleibenden Antwort die Anfrage einfach noch einmal schicken können (ob die erste Anfrage nun angekommen ist oder nicht). Idempotenz ist ebenfalls garantiert für die nicht sicheren Methoden PUT (ein Aktualisieren oder Erzeugen, je nachdem, ob die Ressource vorher schon existierte oder nicht) und DELETE (ein Löschen, das ein zweites Mal ohne Effekt bleibt). Nur für POST, das entweder eine neue Ressource erzeugt oder eine beliebige Verarbeitung anstößt, gibt es keine Garantien. Natürlich sind all diese Garantien aus der Spezifikation nichts wert, wenn die an der Kommunikation beteiligten Partner sie nicht erfüllen. Browser tun das sehr konsequent, für die Serverseite sind – bei einer Webanwendung – Sie verantwortlich.

Aber auch wenn Sie die Funktionalität Ihrer Anwendung für andere Anwendungen in einer REST-konformen Art und Weise nutzbar machen wollen oder eine solche Funktionalität nutzen wollen, gelten dieses Prinzip und seine Restriktionen ebenfalls. Für jemanden, der einen Entwurfsansatz gewohnt ist, bei demman beliebig viele anwendungsspezifische Operationen erfinden kann, ist das schwer zu akzeptieren. Wie soll man allein mit GET, PUT, POST und DELETE auskommen? Es handelt sich dabei allerdings nur scheinbar um ein Problem: Vermeintlich anwendungsspezifische Methoden werden auf die Standard-HTTP-Methoden abgebildet, und um die Mehrdeutigkeit aufzulösen, wird ein ganzes Universum neuer Ressourcen angelegt.

Ein Trick? Nein – ein »GET« auf eine URI, die einen Kunden eindeutig identifiziert, ist genauso bedeutungsvoll wie eine Operation mit dem Namen »get-CustomerDetails«. Gelegentlich benutzt man ein Dreieck, um diesen Effekt darzustellen10:

Abb. 2–1 Das »Options-Dreieck«

Stellen Sie sich die Eckpunkte als Drehregler vor, mit denen Sie beim Modellieren Ihres Systems die Anzahl seiner konzeptuellen Bestandteile anpassen können, bis Ihre Anforderungen vom Systemkonzept abgedeckt werden: Die Anzahl der Operationen, die Ihre Schnittstellen unterstützen, die unterschiedlichen Datentypen, die verwendet werden können, und die Anzahl der Instanzen (»Services« oder »Fassaden« bzw. Ressourcen). Bei dem Ansatz, den Sie gewohnt sind, drehen Sie an der »Operations«- und der »Data types«-Schraube, die Anzahl der Instanzen halten Sie typischerweise konstant (i.d.R. haben Sie so viele Instanzen, wie Sie unterschiedliche Services haben). Beim REST-Ansatz halten Sie die Anzahl der Operationen konstant und benutzen die anderen beiden Regler. Was wir damit sagen möchten: Sie können alles, was Sie mit dem einen Ansatz abbilden, auf den anderen übertragen – nur die Mittel ändern sich.

Dieser Aspekt, entscheidet, ob Ihre Anwendung Teil des Web ist oder nicht: Der Beitrag, den sie zu dessen Wert leistet, ist direkt proportional zur Anzahl der Ressourcen, die sie ihm hinzufügt. In einem REST-konformen Ansatz fügen Sie über Ihre Anwendung dem Web vielleicht eine Million Kunden-URIs hinzu. Wählen Sie stattdessen den althergebrachten CORBA-Stil, wie er bei SOAP-Services auch zum Einsatz kommt, liegt der Wertbeitrag bei einer URI, einem »Endpunkt« – vergleichbar einer Tür, die den Eintritt in ein Universum von Ressourcen nur denjenigen gestattet, die den Schlüssel dazu haben. Analog verhält es sich bei einer Anwendung, die Sie vom Browser aus nutzen und in der sich – obwohl Sie fleißig mit ihr interagieren – die in der Adresszeile angezeigte URI nie ändert: Auch hier haben Sie nur die Anwendung als Ganzes mit einer URI ausgestattet, nicht die vielen sinnvollen, einzelnen Abstraktionen, die sich in ihr verbergen.

Das Standardinterface ermöglicht es allen Komponenten, die das HTTP-Anwendungsprotokoll verstehen, mit Ihrer Applikation zu kommunizieren. Beispiele solcher Komponenten sind außer dem Browser auch andere generische Clients wie curl oder Wget, Proxy-Server, Caches, HTTP-Server, Gateways oder auch Dienste wie Google, Yahoo!, Bing usw.

Zusammenfassung: Damit die Clients, von denen Sie wissen, ebenso wie diejenigen, von denen Sie nichts ahnen, mit Ihren Ressourcen kommunizieren können, sollten alle Ressourcen das Standardanwendungsprotokoll (HTTP) korrekt implementieren.

Ressourcen und Repräsentationen

Eine kleinere Komplikation haben wir bislang ignoriert: Wie weiß ein Client, was er mit den Daten machen soll, die er z. B. als Ergebnis eines GET- oder POST-Requests erhält? Der Ansatz von HTTP ist, eine Trennung der Verantwortlichkeiten für Daten und Operationen einzuführen. Mit anderen Worten: Ein Client, der ein bestimmtes Datenformat verarbeiten – d. h. lesen oder erzeugen – kann, ist in der Lage, mit jeder Ressource zu interagieren, die eine Repräsentation in diesem Format zur Verfügung stellen kann. Die Operationen sind schließlich überall die gleichen. Sehen wir uns dazu wiederum ein Beispiel an. Auf Basis von HTTP Content Negotiation kann ein Client eine Repräsentation in einem bestimmten Format anfordern:

GET /customers/1234 HTTP/1.1Host: example.comAccept: application/vnd.mycompany.customer+xml

Ergebnis könnte hier ein unternehmensspezifisches XML-Format sein, das für Kundeninformationen verwendet wird. Alternativ könnte der Client folgende Anfrage senden:

GET /customers/1234 HTTP/1.1Host: example.comAccept: text/x-vcard

In diesem Fall könnte eine Kundenadresse im vCard-Format zurückgeliefert werden. (Die Antworten sind nicht dargestellt, sie würden Metadaten über das Datenformat im HTTP Content-Type-Header enthalten.) Dies zeigt auch, warum für Repräsentationen idealerweise Standardformate zum Einsatz kommen sollten: Kennt ein Client sowohl das Standardformat als auch das HTTP-Protokoll, kann er mit jeder beliebigen Ressource auf der Welt interagieren, für die eine Repräsentation in diesem Format abrufbar ist. Unglücklicherweise gibt es nicht für alle Anwendungsfälle ein Standardformat, aber Sie können sich sicher vorstellen, wie ein kleineres Ökosystem entstehen könnte, z. B. innerhalb eines Unternehmens oder zwischen Partnern. Natürlich beziehen sich all diese Aussagen nicht nur auf die Daten, die vom Server zum Client gesendet werden, sondern auch auf die Gegenrichtung – jeder Server, der Daten in einem bestimmten Format akzeptieren kann, interessiert sich nicht für die Details des Clients, solange dieser dem Applikationsprotokoll folgt.

Es gibt einen weiteren wichtigen Vorteil durch mehr als eine Repräsentation pro Ressource: Stellen Sie sowohl eine HTML- als auch eine XML-Repräsentation Ihrer Ressourcen zur Verfügung, sind diese nicht nur von Ihrer Clientapplikation, sondern durch jeden Standardwebbrowser darstellbar. Mit anderen Worten: Die Informationen in Ihrer Applikation sind nun für jeden zugänglich, der weiß, wie man mit dem Web umgeht.

Es gibt noch einen anderen Weg, diese Tatsache auszunutzen: Ihre Webanwendung wird zu Ihrem Web-API – schließlich ist das API-Design häufig von der Idee getrieben, dass alles, was man über das User Interface (UI) tun kann, auch über das API möglich sein sollte. Beide Aufgaben zu einer einzigen zu verschmelzen ist ein erstaunlich eleganter Weg, um eine bessere Webschnittstelle sowohl für menschliche als auch maschinelle Nutzer zu erstellen.

Zusammenfassung: Stellen Sie unterschiedliche Repräsentationen Ihrer Ressourcen für unterschiedliche Anforderungen zur Verfügung.

Statuslose Kommunikation

Das fünfte und letzte Prinzip ist die statuslose Kommunikation. »Statuslos« bezieht sich hier nicht etwa auf den serverseitigen Zustand – natürlich kann (und soll) selbiger Zustand halten. Aber REST schreibt vor, dass dieser Zustand entweder vom Client gehalten oder vom Server in einen Ressourcenstatus umgewandelt wird. Nicht gewollt ist ein serverseitig abgelegter, transienter, clientspezifischer Status über die Dauer eines Requests hinweg. Anders formuliert: Der Server interessiert sich für den Client nur, wenn er gerade einen seiner Requests verarbeitet, und kann seine Existenz direkt danach wieder vergessen.

Sie müssen den Zustand also entweder vollständig auf dem Client halten, indem Sie ihn als Teil der Repräsentation vom Server zum Client übermitteln, oder aber in einen Ressourcenstatus umwandeln. Ein Beispiel: Ihr Warenkorb – das klassische Beispiel für einen Sitzungsstatus – wird vielleicht zu einer eigenen Ressource, mit dem Vorteil, dass Sie ein Lesezeichen darauf setzen und einen Link per E-Mail versenden können.

Durch den Verzicht auf einen Sitzungsstatus wird die Kopplung des Clients an den Server verringert, da zwei aufeinanderfolgende Anfragen nicht von der gleichen Serverinstanz bearbeitet werden müssen, wodurch die Skalierbarkeit vereinfacht wird. Die Kopplung wird auch aus anderer Sicht verringert: Ein Client könnte ein Dokument mit Verknüpfungen vom Server beziehen und verarbeiten, während der Server heruntergefahren, Hardware ausgetauscht, das Betriebssystem aktualisiert und das System wieder hochgefahren wird. Folgt der Client zu einem späteren Zeitpunkt einem Link, ist das, was in der Zwischenzeit passiert ist, irrelevant.

2.3 Zusammenfassung

In diesem Kapitel haben Sie den wesentlichen Unterschied zwischen REST als abstraktem Architekturstil und HTTP, URI und den anderen Webstandards als einer konkreten Ausprägung dieses Stils kennengelernt. Darüber hinaus kennen Sie nun die wesentlichen Grundkonzepte: anwendungsübergreifend standardisierte Identifikation, Hypermedia, eine Schnittstelle mit einer fest definierten Menge von Operationen, Ressourcenrepräsentationen und statuslose Kommunikation. Im nächsten Kapitel werden wir uns ansehen, wie man einen konkreten Anwendungsfall auf diese Prinzipien abbilden kann.

3 Fallstudie: OrderManager

Die meisten Online-Tutorials zu REST verwenden eine typische Web-2.0-Anwendung als Beispiel: einen Bookmarking-Dienst wie delicious.com, eine Microblogging-Website wie Twitter oder einen Online-Chatroom. Den Gesetzen der Wahrscheinlichkeit folgend ist die Erstellung einer solchen Anwendung jedoch nicht Ihre primäre Aufgabe – vermutlich haben Sie es in Ihrer täglichen Arbeit mit »bodenständigeren« Anwendungen zu tun.1

Daher haben wir ein eher kommerzielles Beispiel gewählt: ein klassisches Bestellwesen, wie es so oder so ähnlich in einer Vielzahl von Unternehmen existiert (auch wenn es in den meisten davon wahrscheinlich mit Standardsoftware eines Anbieters aus Walldorf umgesetzt wird). Wir werden dieses Beispiel in einer ersten Iteration REST-konform umsetzen, allerdings – wie bereits angekündigt – noch in einer relativ einfachen Form. In Kapitel 14 werden wir die Beispielanwendung auf Basis dessen, was Sie in den Kapiteln dazwischen kennenlernen, noch einmal überarbeiten und erweitern.

3.1 Fachlicher Hintergrund

Unsere Anwendung soll dazu dienen, Bestellungen zu verwalten. Zu diesem Zweck soll sie eine Schnittstelle anbieten, die andere, unternehmensinterne Anwendungen, aber auch externe Partner verwenden können.

Die Anwendung soll dabei zunächst folgende Aufgaben übernehmen:

Verwaltung eingehender Bestellungen mit Bestellstatus, Datum, bestellten Artikeln, Einzel- und Gesamtpreisen, Rechnungs- und Lieferanschrift des Kunden

Statusverwaltung (mit den Status erstellt/in Bearbeitung/fehlgeschlagen/storniert/ausgeliefert)

Unser Fokus liegt dabei auf dem Entwurf der Schnittstellen zu den umliegenden Systemen, nicht auf der Realisierung der Anwendungslogik oder einer Benutzerschnittstelle. Der in diesem Buch zur Verfügung stehende Rahmen reicht für ein komplexes ERP-System natürlich nicht aus, daher vereinfachen wir stark und legen einige mehr oder weniger willkürliche Systemgrenzen fest. Das folgende Diagramm zeigt unser Bestellsystem im Kontext:

Abb. 3–1 Kontextdiagramm OrderManager

Der OrderManager beschäftigt sich also mit Bestellungen, die entweder innerhalb des Unternehmens aufgenommen werden (z. B. in einem Callcenter) oder von Kunden direkt über die Website unseres Beispielunternehmens erfasst werden. Diese vorgelagerten Systeme übermitteln die Bestellungen an den OrderManager. Dieser wiederum ist zwar das führende System für die Bestelldaten, bedient sich aber der Dienste anderer Systeme, wenn er Kunden- oder Artikelstammdaten benötigt. Der OrderManager ist damit ein typisches Backend-System, bei dem wir einen klassischen Enterprise-Ansatz wie CORBA oder SOAP erwarten würden. Wir werden stattdessen REST-Prinzipien und Webtechnologien einsetzen.

In den folgenden Abschnitten betrachten wir die Umsetzung unserer Schnittstellenanforderungen. Es gibt mehrere Aspekte, die bei einem solchen Entwurf zu berücksichtigen sind: Zum einen sollen die zentralen Daten der Domäne mit ihren zugehörigen CRUD-Operationen zur Verfügung gestellt werden. Diese lassen sich in der Regel leicht auf Ressourcen abbilden. Zum anderen müssen aber darüber hinausgehende Systeminteraktionen auf zusätzliche (Aktivitäts-)Ressourcen abgebildet werden. In diesem Kapitel konzentrieren wir uns auf den ersten Aspekt: Zunächst identifizieren wir die zentralen Ressourcen, die an unseren Schnittstellen sichtbar werden. Danach befassen wir uns mit den Formaten, die wir für die Repräsentation dieser Ressourcen einsetzen, den Operationen, die unsere Ressourcen unterstützen, und den Statuscodes, die wir in den Antworten zusätzlich zu unseren Daten erhalten.

3.2 Ressourcen