REST – Grundlagense.uni-hannover.de/priv/lehre_2010sommer_ · – Konflikt bei gleichzeitigem Ändern einer Ressource – Server sendet ETag mit Ressource (kodiert Version) –

REST – Grundlagen

Seminar „Aktuelle Software-Engineering-Praktiken für das World Wide Web“

Olga Liskin<[email protected]>

Olga Liskin: REST - Grundlagen 205.05.2010

Übersicht

• Motivation, Einführung• Architekturstil REST• RESTful Webservices• Patterns, Anti-Patterns• Software Engineering und REST• Code-Beispiele• Zusammenfassung


Einführung

• Erfolg des Web untersuchen• Dissertation von Roy Fielding

– Relevante Faktoren für Web-Systeme aufschreiben– Herangehensweise: Abstraktion zum Architekturstil

• Resultat: Prinzipien für gute Systeme im WWW– Verwendung beim Festlegen von Server-Komponenten und APIs


Motivation

• Vielfältiges Web– Webseiten– „Programmable Web“– Mobile Applikationen

• Viele Service APIs– Viele bezeichnen sich als RESTful– Doch: welche sind wirklich gut?– Wie kann man wirklich gute Systeme bauen?

Quelle: http://maps.google.deQuelle: http://twitter.com


Der Begriff Architekturstil

• System

• Architektur– „Abstraktion der Laufzeit-Elemente eines Systems innerhalb einer

Operationsphase des Systems“ (Fielding)

• Architekturstil– Constraints– Features


REST als Architekturstil

Constraints: Features:

Client-Server Portabilität, Skalierbarkeit, Unabhängige Entwicklung der Komponenten

Statelessness Skalierbarkeit, Einfachheit, Transparenz

Caching Effizienz, Skalierbarkeit

Uniform Interface Skalierbarkeit, Einfachheit, Entwickelbarkeit

Layered System Effizienz, Skalierbarkeit

Code on Demand (opt.) Entwickelbarkeit, Erweiterbarkeit


RESTful Webservices – HTTP

Ausflug: Client-Server-Kommunikation per HTTP• Client sendet Anfrage an Server

– HTTP-Request:GET /users/oliskin HTTP/1.1Host: www.example.orgAccept: text/xml,application/xml,text/htmlAccept-Language: us,enUser-Agent: Mozilla/5.0

• Server bearbeitet Anfrage und sendet eine Antwort– HTTP-Response:

HTTP/1.1 200 OKDate: Wed, 05 May 2010 14:30:00 CETServer: ApacheEtag: „3637586“Content-Type: application/xmlContent-Length: 30229

<?xml version=„1.0“>...

– Kann auch eine Fehlermeldung sein:HTTP/1.1 404 Not FoundContent-Type: text/htmlDate: Wed, 05 May 2010 14:30:00 CETServer: ApacheContent-Length: 30229

<html><head>...


RESTful Webservices – HTTP

Ausflug: Client-Server-Kommunikation per HTTP• Meta-Daten:

– Informationen über Anfrage bzw. mitgelieferte Daten z.B.:• Client:

– Accept– User-Agent– If-Modified-Since

• Response-Codes:– Geben Art der Antwort an, z.B.:

• 200 OK• 201 Created• 301 Moved Permanently• 304 Not Modified• 401 Not Authorized• 409 Conflict

– Response sollte entsprechend bestimmte Meta-Daten enthalten (z.B. neue Adresse bei „301 Moved Permanently“)

• Server:− ETag− Content-Type− Last-Modified


RESTful Webservices – Prinzipien

Wichtige Prinzipien, die Webservices befolgen müssen, um eine REST-konforme Architektur zu erhalten:• Ressourcen• Identifizierbarkeit• Repräsentationen• Verlinkungen• Uniform Interface• Statelessness• Hypermedia as the Engine of Application State (HATEOAS)



Ressourcen• Zentrales Element• Ressource = alles, was ein

Client interessant finden könnte

• „In Ressourcen denken“• Sonst Uniform Interface

nicht möglich

Beispiel: verteilter Notizblock

Ressourcen:Block

Notiz

Benutzer

aber auch z.B.:

Liste von Notizen



Identifizierbarkeit• Jede Ressource soll

eindeutig identifizierbar sein

• Einheitliches Konzept im Web: URI (Uniform Ressource Identifier)

Beispiel:

http://www.example.org/usershttp://www.example.org/users/oliskinhttp://www.example.org/users/oliskin/noteshttp://www.example.org/users/oliskin/notes/note07http://www.example.org/notes?keyword=rest



Repräsentationen• Darstellung einer

Ressource• Verschiedene

Repräsentationen zu einer Ressource– Client sagt, welche Formate

er akzeptiertGET /users/oliskin HTTP/1.1Host: www.example.orgAccept: text/xml,application/xml,text/htmlAccept-Language: us,enUser-Agent: Mozilla/5.0

HTTP/1.1 200 OKDate: Wed, 05 May 2010 14:30:00 CETServer: ApacheEtag: „3637586“Content-Type: application/xmlContent-Length: 30229

<?xml version=„1.0“>...

Beispiel:Ressource: Benutzer oliskin

Repräsentation 1 – XML:

Repräsentation 2 – JSON:

Repräsentation 3 – PNG:



Repräsentationen• Format z.B. durch XML festgelegt• Aber nicht, wie man XML verwendet



Repräsentationen• Besser: Allgemeine Muster verwenden

– XHTML:



Repräsentationen• Besser: Allgemeine Muster verwenden

– Atom:



Verlinkungen• Hypermedien haben

Fähigkeit zur Verlinkung• Erfolg des WWW• Client kann sich durch

Folgen von Links durch das System bewegen

• Hypermedia as the Engine of Application State

Beispiel:XML Beispiel von vorhin:

Besser: Notizen verlinken



Statelessness• Request enthält alle Informationen

die Server zum Ausführen braucht• Server verfolgt nicht den

Anwendungszustand des Clients• URI weitergeben• Server zwischendurch

austauschen



Uniform InterfaceHTTP-Method + URI

GET: Ressource abrufenHEAD: Ressource abrufen (ohne Body)PUT: Ressource anlegen/updatenDELETE: Ressource löschenPOST: Untergeordnete Ressource

anlegen, Daten hintenanhängen

• Idempotenz, Safety

Beispiel:

/users/oliskin/notesGET: Liste von oliskins Notizen abrufenPUT: n/ADELETE: n/APOST: neue Notiz anlegen

/users/oliskinGET: Repräsentation von oliskin abrufenPUT: Benutzer neu anlegen oder

aktualisierenDELETE: Benutzer löschenPOST: n/A



HATEOAS• Trotz generischem Interface

reichhaltige Anwendungen erstellen, nicht nur CRUD

• Verlinkungen schaffen Transitionen

• Vorteile:– Weniger Fehler/Bugs– Weniger ungültige

Transitionen– Server kontrollieren ihren

eigenen Namespace, Clients hängen nicht an festen URI-Mustern

Beispiel:GET users/oliskin/notes HTTP/1.1

<?xml version=“1.0“><notes><note><title>REST ist toll</title><link rel=„Kommentare“

href=„users/oliskin/notes/note08/comments“/>

</note>…

</notes>


Patterns

• Collection-Ressourcen– Eigene Ressource für Liste von Elementen

• Optimistische Transaktionen– Konflikt bei gleichzeitigem Ändern einer Ressource– Server sendet ETag mit Ressource (kodiert Version)– Client sendet Request mit Header If-Match:{ETag}– Bei alter Version: 412 Conflict

• Idempotent Ressourcen anlegen mit POST1. Leere Ressource mit POST anlegen2. Server sendet 301 Created mit URI der neuen Ressource3. Führe nun PUT mit der Ressource auf neue URI aus -> Idempotent


Anti-Patterns

• Tunnelung von Methoden mit POST– Es wird immer POST verwendet, Methoden-Information wird im Entity-

Body versteckt– Uniform Interface?

• Tunnelung von Methoden mit GET– Ähnlich Tunnelung mit POST– Zusätzlich: GET sollte eigentlich safe sein

• Mangelnde Verwendung von Hypermedien/-links– „Web-Based CRUD“*– Client kann sich nicht durch Folgen von Links durch das System

bewegen– HATEOAS?

* Tilkov, S. REST Anti-Patterns. http://www.infoq.com/articles/rest-anti-patterns (Stand: 25.04.2010)


Software Engineering-Prinzipien

• Aufstellung und Verwendung von Architekturen– Abstraktion des Systems

• Architekturstil– „Pattern für Architekturen“– Erfahrung beim Entwickeln von Architekturen ausnutzen

• (Anti-)Patterns verwenden• Gemeinsame Muster entwerfen und verwenden

– URI, HTTP– Syndication Formate


Code schreiben

Client• Bestehende Webservices ansprechen• Meistens über Standard-Bibliotheken• HTTP Request senden• Antwort parsen (z.B. XML)


Code schreiben

Beispiel: Java HttpClient (Apache Jakarta Project)


Code schreiben

Server• Verschiedene Frameworks

– JAX RS (JSR 311) (Schnittstellenspezifikation für Java)• Jersey• Restlet• JBoss RestEasy

– Ruby on Rails


Code schreiben

ServerBeispiel: Jersey (Annotations-getrieben)


Code schreiben

ServerBeispiel: Ruby on Rails (Konnektoren)(Ausführliches Beispiel in: Richardson; Ruby: RESTful Web Services. O‘Reilly. 2007)


Zusammenfassung

• Verbesserung von Systemen im Web• Relevante Prinzipien identifizieren: REST als Architekturstil• Prinzipien beim Design von Anwendungen (z.B.Webservices)

verwenden• Patterns und Anti-Patterns• Umsetzung in Code


Zusammenfassung

Fragen?

Diskussionsidee:Sind Patterns/Anti-Patterns der Schlüssel zu „RESTfulleren“ Webservices?

Was können wir als Software-Ingenieure noch beisteuern, um RESTfulness zu verbessern?

Validatoren, DODEs? Bessere Frameworks, DSLs?,

„Berühmtere“ Patterns?

Documents

REST – Grundlagense.uni-hannover.de/priv/lehre_2010sommer_ · – Konflikt bei gleichzeitigem Ändern einer Ressource – Server sendet ETag mit Ressource (kodiert Version) –