© Mayflower GmbH 2010

RESTful WebServices

Paul Seiffert I 03.11.11

Mayflower GmbH I 2

Paul Seiffert

I Developer @ Mayflower

I PHP seit ca. 8 Jahren

I Mobile Application Development

I B.Sc. Computer Science (TU München)

I facebook.com/seiffertp

Mayflower GmbH I 3

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

Mayflower GmbH I 4

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

Mayflower GmbH I 5

HTTP als Netzwerkarchitektur I

I HTTP ist eine von vielen Netzwerk möglichen Netzwerk-Architekturen

→Was macht HTTP besonders?

LCoDC$SS

Mayflower GmbH I 6

HTTP als Netzwerkarchitektur II - LCoDC$SS

I Client-Server-Architektur → Separation of Concerns → Skalierbarkeit → Portabilität

Mayflower GmbH I 7

HTTP als Netzwerkarchitektur III - LCoDC$SS

I Layered System and Layered Client-Server → Netzwerk-Architektur - OSI-Modell →Multi-Tier-Architekturen

(Caches, Proxies, Gateways, …)

→ Geringere Komplexität → Aber: Höhere Latenzen

Mayflower GmbH I 8

HTTP als Netzwerkarchitektur IV - LCoDC$SS

I Stateless Server

· Jeder Request beinhaltet alle Informationen,um die Anfrage zu beantworten

· Server hält keine Informationen über den Application State

· Cookies sind OK, Session-IDs meist nicht

· Sichtbarkeit: Monitoring vereinfacht

· Skalierbarkeit: Server braucht keine Session-Informationen zu speichern

· Aber: Mehr Netzwerk-Traffic

Mayflower GmbH I 9

HTTP als Netzwerkarchitektur V - LCoDC$SS

I Caching

· Clientseitige Caches veringern die Anzahl notwendiger Requests

· Serverseitige Caches veringern Ressourcenverbrauch und Bearbeitungszeit

Mayflower GmbH I 10

HTTP als Netzwerkarchitektur VI - LCoDC$SS

I Code on Demand

· Server liefert neben Daten auch Logik aus

· Client stellt nur eine generische Ausführungsumgebung zur Verfügung (Rendering-Engine, JavaScript)

· Einfaches Deployment

Mayflower GmbH I 11

HTTP als Netzwerkarchitektur VII - LCoDC$SS

L Layered

CoD Code on Demand

C Client

$ Cache

S Stateless

S Server

Netzwerk-Architektur von

HTTP

Mayflower GmbH I 12

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

Mayflower GmbH I 13

HTTP: Addressierbarkeit I - Begriffe

I Die Objekte in HTTP heißen Ressourcen

I Operationen auf Ressourcen sind HTTP-Requests

I HTTP-Requests benötigen eine Information, welche Ressource angesprochen wird

· URI (Universal Resource Identifier)

Mayflower GmbH I 14

HTTP: Addressierbarkeit II – Ressourcen URIs↔

I Jede Ressource hat genau eine URI

I Jede URI verweist genau auf eine Ressource

I Eine Ressource kann jedoch unterschiedliche Repräsentationen besitzen

Mayflower GmbH I 15

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

Mayflower GmbH I 16

HTTP: Verbs / Methods I

I Durch Addressierbarkeit ist der Scope eines Requests gegeben

I Die auszuführende Aktion wird durch die HTTP-Methode festgelegt

I Die Menge der HTTP-Methoden stellt alle auf einer Ressource ausführbaren Aktionen dar

Mayflower GmbH I 17

HTTP: Verbs / Methods II

GETHEAD

PUTDELETE

POST

OPTIONS

TRACE

CONNECT

Mayflower GmbH I 18

HTTP: Verbs / Methods III – Sichere Methoden

GETHEAD

I GET und HEAD sind sicher

· Sie verändern den Zustand einer Ressource nicht

· Cachable

I GET liefert eine Repräsentation einer Ressource samt ihrer Metadaten zurück

I HEAD liefert nur die Metadaten einer Repräsentation einer Ressource zurück

Mayflower GmbH I 19

REST – 1x1 - GET

GET /blog/restful-webservices HTTP/1.1Host: example.comAccept: application/json

HTTP/1.1 200 OKServer: nginx/1.0.6Content-Type: application/jsonContent-Length: 123{ title: 'RESTful WebServices', content: '…', author: 'Paul Seiffert', Date: '2011/10/20 18:00:00'}

Mayflower GmbH I 20

REST – 1x1 - HEAD

HEAD /blog/restful-webservices HTTP/1.1Host: example.comAccept: application/json

HTTP/1.1 200 OKServer: nginx/1.0.6Content-Type: application/jsonContent-Length: 123

Mayflower GmbH I 21

HTTP: Verbs / Methods IV – Idempotente Methoden

GETHEAD

PUTDELETE

I GET, HEAD, PUT und DELETE sind idempotent → f(x) = f(f(x))

I Idempotente Aktionen können ohne Nebeneffekte wiederholt ausgeführt werden

Mayflower GmbH I 22

HTTP: Verbs / Methods IV – Idempotente Methoden

GETHEAD

PUTDELETE

I PUT erstellt bzw. überschreibt eine Ressource

I DELETE löscht eine Ressource

Mayflower GmbH I 23

REST – 1x1 - PUT

PUT /blog/restful-webservices HTTP/1.1Host: example.com{ title: 'RESTful WebServices', content: '…', author: 'Leonard Richardson', Date: '2011/10/20 18:00:00'}

HTTP/1.1 200 OKServer: nginx/1.0.6

Mayflower GmbH I 24

REST – 1x1 - DELETE

DELETE /blog/restful-webservices-2 HTTP/1.1Host: example.com

HTTP/1.1 200 OKServer: nginx/1.0.6

Mayflower GmbH I 25

HTTP: Verbs / Methods V – POST

I POST ist weder sicher noch idempotent → Mit Vorsicht zu genießen

I POST fügt an eine Ressource eine(Unter-)Ressource an

I Beispiel: Hinzufügen eines Blog-Posts

Mayflower GmbH I 26

REST – 1x1 - POST

POST /blog HTTP/1.1Host: example.comtitle=RESTful WebServices 2&content=…&author='Leonard Richardson'&Date=2011/10/20 18:30:00

HTTP/1.1 201 CREATEDServer: nginx/1.0.6Location: /blog/restful-webservices-2

Mayflower GmbH I 27

I POST ist die HTTP-Methode, die am meisten falsch genutzt wird

Problem? → Ergebnis nicht Cachebar → Ergebnis nicht Addressierbar

HTTP: Verbs / Methods V – POST

<form action=“/search“ method=“POST“><input type=“text“ name=“term“ /><input type=“submit“ value=“Search!“ />

</form>

Mayflower GmbH I 28

I GET und HEAD sind verpflichtend!

I Alle anderen Methoden sind optional

· Wenn jedoch implementiert, müssen sie der beschriebenen Semantik entsprechen

I Ein OPTIONS-Request deckt auf, welche Methoden auf eine Ressource anwendbar sind

HTTP: Verbs / Methods VI – Regeln

Mayflower GmbH I 29

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

Mayflower GmbH I 30

I Ressourcen verweisen aufeinander und geben somit mögliche Wege durch die Anwendung vor

I Neben Links stehen andere Mechanismen wie Formulare zur Verfügung

· Formulare sagen aus, wie Ressourcen editiert werden können

I Durch den Einsatz von Hypermedia lassen sich generische Clients für RESTful HTTP-Applikationen entwickeln

HTTP: Hypermedia I

Mayflower GmbH I 31

I HATEOAS

Hypermedia as the engine of application state

· Application state liegt komplett auf dem Client

· Mögliche Folgezustände sind durch Hypermedia festgelegt

· URIs lassen sich einfach ändern

· Weniger Logik im Client-Code notwendig

HTTP: Hypermedia II

Mayflower GmbH I 32

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

Mayflower GmbH I 33

REST ??

Mayflower GmbH I 34

Agenda

1) HTTP als Netzwerkarchitektur

2) HTTP: Addressierbarkeit

3) HTTP: Verbs / Methods

4) HTTP: Hypermedia

5) REST

Mayflower GmbH I 35

I HTTP mit Einschränkungen:

1. Addressability

2. Statelessness

3. Connectedness

4. A uniform interface

REST

Mayflower GmbH I 36

I URIs in RESTful WebServices sollena) … sprechend sein.

b) … die Hierarchie der referenzierten Ressourcen abbilden

REST - URIs

BAD:http://example.com/index.php?module=blog&action=view_post&post_id=123GOOD:http://exmple.com/blog/restful-webservices.html

BAD:http://example.com/blog/comments/restful-webservices.htmlGOOD:http://exmple.com/blog/restful-webservices/comments.html

Mayflower GmbH I 37

I Ressourcen verweisen auf andere Ressourcen

· Generische REST-Clients sind möglich!

I Formulare beschreiben, wie eine Ressource editiert werden kann

REST - Connectedness

Mayflower GmbH I 38

I Ressourcen werden mit HTTP-Verbs angesprochen

I Antworten sind selbsterklärend

· HTTP-Statuscodes

· Standard HTTP-Header

REST – Uniform Interface

Mayflower GmbH I 39

I Level 0: Eine HTTP-Method, Eine Ressource (SOAP)

I Level 1: Eine HTTP-Method, Viele Ressourcen (Viele Webseiten)

I Level 2: Mehrere HTTP-Methods, Viele Ressourcen (Die meisten „REST-WebServices“)

I Level 3: Level 2 + Hypermedia (RESTful WebServices)

REST – Richardson's Maturity Model

10.11.11 Mayflower GmbH 40

Vielen Dank für Eure Aufmerksamkeit!

Referent Paul Seiffert

Paul.Seiffert@mayflower.de

+49 89 242054 1172

Mayflower GmbH

Mannhardtstrasse6

80538 München

Mayflower GmbH I 41

I Leonard Richardson & Sam Ruby - RESTful Web Services

I Roy Thomas Fielding - Architectural Styles and the Design of Network-based Software Architectures

I Martin Fowler - Richardson Maturity Model

I QAFOO-Talk "HTTP is your architecture"

I http://www.crummy.com/writing/speaking/2008-QCon/act3.html

I http://www.slideshare.net/Wombert/designing-http-interfaces-and-restful-web-services-ipc11-20111011

Literatur

Mayflower GmbH I 42

I Authentifizierung ohne Sessions?? → HTTP-Auth (Basic, Digest, …) → Auth-Token wird bei jedem Request mitgesendet

Authentifizierung

GET /anything.html HTTP/1.1Host: www.example.com401 UnauthorizedWWW-Authenticate: Basic realm=“This is a secret place!“GET /anything.html HTTP/1.1Host: www.example.comAuthorization: Basic <TOKEN>

Mayflower GmbH I 43

HTTP-Statuscode - 1x1

I 200: OK

I 201: Created

I 400: Bad Request (Client-Seitiger Fehler)

I 500: Internal Server Error

I 301: Moved Permanently

I 404: Not Found

I 409: Conflict

Mayflower GmbH I 44

HTTP-Headers – 1x1 I

I AcceptRequest-Header. Teilt das gewünschte Response-Format mit.

I AllowResponse-Header. Sagt aus, welche Methoden auf einer Ressource möglich sind

I AuthorizationRequest-Header, der die Authentifizierungs- bzw. Authorisierungs-Credentials beinhaltet

I Content-LengthResponse-Header. Länge des Response-Body

Mayflower GmbH I 45

HTTP-Headers – 1x1 II

I Content-TypeResponse-Header, der den Mime-Type der mitgelieferten Repräsentation angibt

I DateGibt bei jedem Request und jeder Response das Sende-Datum an

I HostRequest-Header, der den Namen des HTTP-Servers angibt

I LocationResponse-Header, der in verschiedenen Fällen genutzt wird um den Client die URI einer Resource mitzuteilen

Mayflower GmbH I 46

HTTP-Headers – 1x1 III

I User-AgentRequest-Header, der die HTTP-Client-Software beschreibt