RESTful WebServices

  • 4,812 views
Uploaded on

HTTP ist das Protokoll, auf dem das WWW aufsetzt. Obwohl es ein sehr einfaches Protokoll ist, finden sich heute kaum Webseiten und -services, die HTTP richtig umsetzen und somit seine gesamten …

HTTP ist das Protokoll, auf dem das WWW aufsetzt. Obwohl es ein sehr einfaches Protokoll ist, finden sich heute kaum Webseiten und -services, die HTTP richtig umsetzen und somit seine gesamten Vorteile ausschöpfen. Der Vortrag REST WebServices von Paul Seiffert handelt im ersten Teil von HTTP und stellt im zweiten REST vor - die Verbindung von HTTP mit einer Resource-Oriented-Architecture (ROA).

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
4,812
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
31
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. RESTful WebServicesPaul Seiffert I 03.11.11 © Mayflower GmbH 2010
  • 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 2
  • 3. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia Mayflower GmbH I 3
  • 4. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia Mayflower GmbH I 4
  • 5. HTTP als Netzwerkarchitektur II HTTP ist eine von vielen Netzwerk möglichen Netzwerk- Architekturen → Was macht HTTP besonders? LCoDC$SS Mayflower GmbH I 5
  • 6. HTTP als Netzwerkarchitektur II - LCoDC$SSI Client-Server-Architektur → Separation of Concerns → Skalierbarkeit → Portabilität Mayflower GmbH I 6
  • 7. HTTP als Netzwerkarchitektur III - LCoDC$SSI 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
  • 8. HTTP als Netzwerkarchitektur IV - LCoDC$SSI 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
  • 9. HTTP als Netzwerkarchitektur V - LCoDC$SSI Caching · Clientseitige Caches veringern die Anzahl notwendiger Requests · Serverseitige Caches veringern Ressourcenverbrauch und Bearbeitungszeit Mayflower GmbH I 9
  • 10. HTTP als Netzwerkarchitektur VI - LCoDC$SSI 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
  • 11. 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
  • 12. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia Mayflower GmbH I 12
  • 13. HTTP: Addressierbarkeit I - BegriffeI Die Objekte in HTTP heißen RessourcenI Operationen auf Ressourcen sind HTTP-RequestsI HTTP-Requests benötigen eine Information, welche Ressource angesprochen wird · URI (Universal Resource Identifier) Mayflower GmbH I 13
  • 14. HTTP: Addressierbarkeit II – Ressourcen ↔ URIsI Jede Ressource hat genau eine URII Jede URI verweist genau auf eine RessourceI Eine Ressource kann jedoch unterschiedliche Repräsentationen besitzen Mayflower GmbH I 14
  • 15. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia Mayflower GmbH I 15
  • 16. HTTP: Verbs / Methods II Durch Addressierbarkeit ist der Scope eines Requests gegebenI Die auszuführende Aktion wird durch die HTTP-Methode festgelegtI Die Menge der HTTP-Methoden stellt alle auf einer Ressource ausführbaren Aktionen dar Mayflower GmbH I 16
  • 17. HTTP: Verbs / Methods II OPTIONS GET PUT HEAD DELETE TRACE CONNECT POST Mayflower GmbH I 17
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. HTTP: Verbs / Methods IV – Idempotente Methoden GET PUT HEAD DELETEI 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
  • 22. HTTP: Verbs / Methods IV – Idempotente Methoden GET PUT HEAD DELETEI PUT erstellt bzw. überschreibt eine RessourceI DELETE löscht eine Ressource Mayflower GmbH I 22
  • 23. 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
  • 24. 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
  • 25. HTTP: Verbs / Methods V – POSTI POST ist weder sicher noch idempotent → Mit Vorsicht zu genießenI POST fügt an eine Ressource eine (Unter-)Ressource anI Beispiel: Hinzufügen eines Blog-Posts Mayflower GmbH I 25
  • 26. 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
  • 27. HTTP: Verbs / Methods V – POSTI 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
  • 28. HTTP: Verbs / Methods VI – RegelnI GET und HEAD sind verpflichtend!I Alle anderen Methoden sind optional · Wenn jedoch implementiert, müssen sie der beschriebenen Semantik entsprechenI Ein OPTIONS-Request deckt auf, welche Methoden auf eine Ressource anwendbar sind Mayflower GmbH I 28
  • 29. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia Mayflower GmbH I 29
  • 30. HTTP: Hypermedia II Ressourcen verweisen aufeinander und geben somit mögliche Wege durch die Anwendung vorI Neben Links stehen andere Mechanismen wie Formulare zur Verfügung · Formulare sagen aus, wie Ressourcen editiert werden könnenI Durch den Einsatz von Hypermedia lassen sich generische Clients für RESTful HTTP-Applikationen entwickeln Mayflower GmbH I 30
  • 31. HTTP: Hypermedia III 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
  • 32. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia Mayflower GmbH I 32
  • 33. REST ?? Mayflower GmbH I 33
  • 34. Agenda1) HTTP als Netzwerkarchitektur2) HTTP: Addressierbarkeit3) HTTP: Verbs / Methods4) HTTP: Hypermedia5) REST Mayflower GmbH I 34
  • 35. RESTI HTTP mit Einschränkungen: 1. Addressability 2. Statelessness 3. Connectedness 4. A uniform interface Mayflower GmbH I 35
  • 36. REST - URIsI 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
  • 37. REST - ConnectednessI Ressourcen verweisen auf andere Ressourcen · Generische REST-Clients sind möglich!I Formulare beschreiben, wie eine Ressource editiert werden kann Mayflower GmbH I 37
  • 38. REST – Uniform InterfaceI Ressourcen werden mit HTTP-Verbs angesprochenI Antworten sind selbsterklärend · HTTP-Statuscodes · Standard HTTP-Header Mayflower GmbH I 38
  • 39. REST – Richardsons Maturity ModelI 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
  • 40. Vielen Dank für Eure Aufmerksamkeit! Referent Paul Seiffert Paul.Seiffert@mayflower.de +49 89 242054 1172 Mayflower GmbH Mannhardtstrasse6 80538 München10.1 1 1.1 Mayflower GmbH 40
  • 41. LiteraturI Leonard Richardson & Sam Ruby - RESTful Web ServicesI Roy Thomas Fielding - Architectural Styles and the Design of Network- based Software ArchitecturesI Martin Fowler - Richardson Maturity ModelI QAFOO-Talk "HTTP is your architecture"I http://www.crummy.com/writing/speaking/2008-QCon/act3.htmlI http://www.slideshare.net/Wombert/designing-http-interfaces-and- restful-web-services-ipc11-201 101 1 1 Mayflower GmbH I 41
  • 42. AuthentifizierungI Authentifizierung ohne Sessions?? → HTTP-Auth (Basic, Digest, …) → Auth-Token wird bei jedem Request mitgesendetGET /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 42
  • 43. HTTP-Statuscode - 1x1I 200: OKI 201: CreatedI 400: Bad Request (Client-Seitiger Fehler)I 500: Internal Server ErrorI 301: Moved PermanentlyI 404: Not FoundI 409: Conflict Mayflower GmbH I 43
  • 44. HTTP-Headers – 1x1 II Accept Request-Header. Teilt das gewünschte Response-Format mit.I Allow Response-Header. Sagt aus, welche Methoden auf einer Ressource möglich sindI Authorization Request-Header, der die Authentifizierungs- bzw. Authorisierungs- Credentials beinhaltetI Content-Length Response-Header. Länge des Response-Body Mayflower GmbH I 44
  • 45. HTTP-Headers – 1x1 III Content-Type Response-Header, der den Mime-Type der mitgelieferten Repräsentation angibtI Date Gibt bei jedem Request und jeder Response das Sende-Datum anI Host Request-Header, der den Namen des HTTP-Servers angibtI Location Response-Header, der in verschiedenen Fällen genutzt wird um den Client die URI einer Resource mitzuteilen Mayflower GmbH I 45
  • 46. HTTP-Headers – 1x1 IIII User-Agent Request-Header, der die HTTP-Client-Software beschreibt Mayflower GmbH I 46