44-mal heruntergeladen
Hochgeladen vonMayflower GmbH
RESTful WebServices
Das Dokument befasst sich mit HTTP als Netzwerkarchitektur und den damit verbundenen Konzepten wie Addressierbarkeit, HTTP-Methoden und Hypermedia. Es werden die Prinzipien von RESTful Web Services erläutert, einschließlich deren Anforderungen an Zustandslosigkeit, Adressierbarkeit und die Nutzung einer einheitlichen Schnittstelle. Zudem werden verschiedene HTTP-Methoden und deren Anwendungen sowie die Relevanz von Hypermedia in REST-Architekturen diskutiert.
RESTful WebServices
- 1. RESTful WebServices Paul SeiffertI 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. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia Mayflower GmbH I 3
- 4. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia Mayflower GmbH I 4
- 5. HTTP als NetzwerkarchitekturI I HTTP ist eine von vielen Netzwerk möglichen Netzwerk- Architekturen → Was macht HTTP besonders? LCoDC$SS Mayflower GmbH I 5
- 6. HTTP als NetzwerkarchitekturII - LCoDC$SS I Client-Server-Architektur → Separation of Concerns → Skalierbarkeit → Portabilität Mayflower GmbH I 6
- 7. HTTP als NetzwerkarchitekturIII - 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
- 8. HTTP als NetzwerkarchitekturIV - 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
- 9. HTTP als NetzwerkarchitekturV - LCoDC$SS I Caching · Clientseitige Caches veringern die Anzahl notwendiger Requests · Serverseitige Caches veringern Ressourcenverbrauch und Bearbeitungszeit Mayflower GmbH I 9
- 10. HTTP als NetzwerkarchitekturVI - 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
- 11. HTTP als NetzwerkarchitekturVII - LCoDC$SS L Layered CoD Code on Demand C Client Netzwerk-Architektur von $ Cache HTTP S Stateless S Server Mayflower GmbH I 11
- 12. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia Mayflower GmbH I 12
- 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 13
- 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 14
- 15. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia Mayflower GmbH I 15
- 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 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 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
- 22. 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
- 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 – 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
- 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 – 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
- 28. 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
- 29. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia Mayflower GmbH I 29
- 30. HTTP: Hypermedia I IRessourcen 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
- 31. HTTP: Hypermedia II IHATEOAS 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. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia Mayflower GmbH I 32
- 33. REST ?? Mayflower GmbH I 33
- 34. Agenda 1) HTTP als Netzwerkarchitektur 2) HTTP: Addressierbarkeit 3) HTTP: Verbs / Methods 4) HTTP: Hypermedia 5) REST Mayflower GmbH I 34
- 35. REST I HTTP mitEinschränkungen: 1. Addressability 2. Statelessness 3. Connectedness 4. A uniform interface Mayflower GmbH I 35
- 36. REST - URIs IURIs 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 - Connectedness IRessourcen 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 – UniformInterface I Ressourcen werden mit HTTP-Verbs angesprochen I Antworten sind selbsterklärend · HTTP-Statuscodes · Standard HTTP-Header Mayflower GmbH I 38
- 39. REST – Richardson'sMaturity 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
- 40. Vielen Dank fürEure 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
- 41. 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
- 42. Authentifizierung I Authentifizierung ohneSessions?? → 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
- 43. HTTP-Statuscode - 1x1 I200: 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
- 44. HTTP-Headers – 1x1I 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
- 45. HTTP-Headers – 1x1II 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
- 46. HTTP-Headers – 1x1III I User-Agent Request-Header, der die HTTP-Client-Software beschreibt Mayflower GmbH I 46