RESTful WebServices

RESTful WebServices

Paul Seiffert I 03.11.11

© Mayflower GmbH 2010

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 2

Agenda

1) HTTP als Netzwerkarchitektur
2) HTTP: Addressierbarkeit
3) HTTP: Verbs / Methods
4) HTTP: Hypermedia

Mayflower GmbH I 3

Agenda

4) HTTP: Hypermedia

Mayflower GmbH I 4

HTTP als Netzwerkarchitektur I

I HTTP ist eine von vielen Netzwerk möglichen Netzwerk-
Architekturen
→ Was macht HTTP besonders?

LCoDC$SS

Mayflower GmbH I 5

HTTP als Netzwerkarchitektur II - LCoDC$SS

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

Mayflower GmbH I 6

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 7

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 8

HTTP als Netzwerkarchitektur V - LCoDC$SS

I Caching
· Clientseitige Caches veringern die Anzahl
notwendiger Requests

· Serverseitige Caches veringern
Ressourcenverbrauch und Bearbeitungszeit

Mayflower GmbH I 9

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 10

HTTP als Netzwerkarchitektur VII - LCoDC$SS

L Layered
CoD Code on Demand
C Client Netzwerk-Architektur von
$ Cache HTTP
S Stateless
S Server

Mayflower GmbH I 11

Agenda

4) HTTP: Hypermedia

Mayflower GmbH I 12

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 13

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 14

Agenda

4) HTTP: Hypermedia

Mayflower GmbH I 15

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 16

HTTP: Verbs / Methods II

OPTIONS
GET PUT

HEAD DELETE TRACE

CONNECT
POST

Mayflower GmbH I 17

HTTP: Verbs / Methods III – Sichere Methoden

I GET und HEAD sind sicher
·Sie verändern den Zustand einer
GET Ressource nicht
·Cachable
HEAD
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 18

REST – 1x1 - GET

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

HTTP/1.1 200 OK
Server: nginx/1.0.6
Content-Type: application/json
Content-Length: 123

{
title: 'RESTful WebServices',
content: '…',
author: 'Paul Seiffert',
Date: '2011/10/20 18:00:00'
}

Mayflower GmbH I 19

REST – 1x1 - HEAD

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

HTTP/1.1 200 OK
Server: nginx/1.0.6
Content-Type: application/json
Content-Length: 123

Mayflower GmbH I 20

HTTP: Verbs / Methods IV – Idempotente Methoden

GET PUT

HEAD DELETE

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 21

HTTP: Verbs / Methods IV – Idempotente Methoden

GET PUT

HEAD DELETE

I PUT erstellt bzw. überschreibt eine Ressource
I DELETE löscht eine Ressource

Mayflower GmbH I 22

REST – 1x1 - PUT

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

{
title: 'RESTful WebServices',
content: '…',
author: 'Leonard Richardson',
Date: '2011/10/20 18:00:00'
}

HTTP/1.1 200 OK
Server: nginx/1.0.6

Mayflower GmbH I 23

REST – 1x1 - DELETE

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

HTTP/1.1 200 OK
Server: nginx/1.0.6

Mayflower GmbH I 24

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 25

REST – 1x1 - POST

POST /blog HTTP/1.1
Host: example.com

title=RESTful WebServices 2
&content=…&author='Leonard Richardson'
&Date=2011/10/20 18:30:00

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

Mayflower GmbH I 26

HTTP: Verbs / Methods V – POST

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

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

Problem?
→ Ergebnis nicht Cachebar
→ Ergebnis nicht Addressierbar

Mayflower GmbH I 27

HTTP: Verbs / Methods VI – Regeln

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

Mayflower GmbH I 28

Agenda

4) HTTP: Hypermedia

Mayflower GmbH I 29

HTTP: Hypermedia I

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

Mayflower GmbH I 30

HTTP: Hypermedia II

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

Mayflower GmbH I 31

Agenda

4) HTTP: Hypermedia

Mayflower GmbH I 32

REST ??

Mayflower GmbH I 33

Agenda

4) HTTP: Hypermedia
5) REST

Mayflower GmbH I 34

REST

I HTTP mit Einschränkungen:

1. Addressability

2. Statelessness

3. Connectedness

4. A uniform interface

Mayflower GmbH I 35

REST - URIs

I URIs in RESTful WebServices sollen
a) … sprechend sein.
BAD:
http://example.com/index.php?module=blog&action=view_post&post_id=123
GOOD:
http://exmple.com/blog/restful-webservices.html

b) … die Hierarchie der referenzierten Ressourcen abbilden
BAD:
http://example.com/blog/comments/restful-webservices.html

GOOD:
http://exmple.com/blog/restful-webservices/comments.html

Mayflower GmbH I 36

REST - Connectedness

I Ressourcen verweisen auf andere Ressourcen
· Generische REST-Clients sind möglich!

I Formulare beschreiben, wie eine Ressource editiert werden kann

Mayflower GmbH I 37

REST – Uniform Interface

I Ressourcen werden mit HTTP-Verbs angesprochen

I Antworten sind selbsterklärend
· HTTP-Statuscodes
· Standard HTTP-Header

Mayflower GmbH I 38

REST – Richardson's Maturity Model

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)

Mayflower GmbH I 39

Vielen Dank für Eure Aufmerksamkeit!

Referent Paul Seiffert
Paul.Seiffert@mayflower.de
+49 89 242054 1172

Mayflower GmbH
Mannhardtstrasse6
80538 München

10.1 1
1.1 Mayflower GmbH 40

Literatur

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-201 101
1 1

Mayflower GmbH I 41

Authentifizierung

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

GET /anything.html HTTP/1.1
Host: www.example.com

401 Unauthorized
WWW-Authenticate: Basic realm=“This is a secret place!“

GET /anything.html HTTP/1.1
Host: www.example.com
Authorization: Basic <TOKEN>

Mayflower GmbH I 42

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 43

HTTP-Headers – 1x1 I

I Accept
Request-Header. Teilt das gewünschte Response-Format mit.
I Allow
Response-Header. Sagt aus, welche Methoden auf einer Ressource
möglich sind
I Authorization
Request-Header, der die Authentifizierungs- bzw. Authorisierungs-
Credentials beinhaltet
I Content-Length
Response-Header. Länge des Response-Body

Mayflower GmbH I 44

HTTP-Headers – 1x1 II

I Content-Type
Response-Header, der den Mime-Type der mitgelieferten
Repräsentation angibt
I Date
Gibt bei jedem Request und jeder Response das Sende-Datum an
I Host
Request-Header, der den Namen des HTTP-Servers angibt
I Location
Response-Header, der in verschiedenen Fällen genutzt wird um den
Client die URI einer Resource mitzuteilen

Mayflower GmbH I 45

HTTP-Headers – 1x1 III

I User-Agent
Request-Header, der die HTTP-Client-Software beschreibt

Mayflower GmbH I 46

RESTful WebServices

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (17)

Similar a RESTful WebServices

Similar a RESTful WebServices (20)

Más de Mayflower GmbH

Más de Mayflower GmbH (20)

RESTful WebServices