Downloaden Sie, um offline zu lesen
Hochgeladen vonMaximilian Berghoff
Rest
Die Präsentation befasst sich mit REST, einem Architekturstil für Webservices, und erläutert Grundlagen wie HTTP-Anfragen und -Antworten, Statuscodes sowie REST-Operationen. Beispiele werden gegeben, um REST-Methoden wie GET, POST, PUT und DELETE zu veranschaulichen, zusammen mit der Bedeutung von Ressourcen und deren Adressierbarkeit. Zudem wird das FOSRestBundle in Symfony als Tool zur (De-)Serialisierung in REST-Anwendungen vorgestellt.
Rest
- 1. REST PHP User Group| 24.10.2013 Maximilian Berghoff @ElectricMaxxx
- 2. Agenda 1. Einführung, Begriffsklärungund HTTP 2. Praxisbeispiel 3. FOSRestBundle
- 3.
- 4. HTTP Basics Request <->Response
- 5. HTTP Basics -Request Der Brief wird losgeschickt ...
- 6. HTTP Basics -Request HTTP - Header GET /my/path HTTP/1.1 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0. 8 Accept-Language:en-US,en;q=0.8 Cache-Control:max-age=0 Connection:keep-alive Host: www.example.de User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/28.0.1500.71 Chrome/28.0.1500.71 Safari/537.36
- 7. HTTP Basics -Response HTTP - Header HTTP/1.1 200 OK Connection:keep-alive Content-Type: text/html; charset=UTF-8 Date: Mon, 21 Oct 2013 12:20:55 GMT Last-Modified: Mon, 21 Oct 2013 08:34:57 GMT Content-Length: …
- 8. HTTP - Basics- Statuscode 1xx - Antwort dauert noch an 2xx - Erfolgreiche Operation 3xx - Umleitung 4xx - Client-Fehler 5xx - Server-Fehler (Liste: http://de.wikipedia.org/wiki/HTTP-Statuscode)
- 9. REST • • • • WebService (neben SOAP,XML-RPC) kein fester Standart, viele Ideen geht aus Dissertation v. Roy Fielding (2000) hervor “lebt” HTTP
- 10. WebService - Resourcen Objekte,Dinge, Entitäten, ...
- 11. WebService - Resourcen Beispiele: – – – – ErsterEintrag in einem Webblog letzte Softwareversion Quartalszahlen Karte für eine Region
- 12. WebService - Methoden Wassoll ich tun?
- 13. WebServices Unterscheiden sich durch: •Angabe der Resource • Angabe der Methode • Quantität der Methoden
- 14.
- 15.
- 16. WebService Beispiel(REST) • • • • • • • GET http://www.example.de/api/user GEThttp://www.example.de/api/user/12 POST http://www.example.de/api/user PUT http://www.example.de/api/user/12 DELETE http://www.example.de/api/user OPTION http://www.example.de/api/user HEAD http://www.example.de/api/user
- 17.
- 18.
- 19. REST - State ApplicationState vs. Resource State
- 20.
- 21. REST - Repräsentation HTTP- Header (Request) – – – Accept Accept-Language Authentification
- 22. REST - Repräsentation HTTP- Header (Response) – – Content-Type Content-Language
- 23. REST - Repräsentation URI •http://example.de/api/article/en • http://example.de/api/article/es
- 24.
- 25. REST - Operationen GET,HEAD, OPTIONS
- 26.
- 27.
- 28.
- 29.
- 30. REST - Operationen(POST) • • • • Kommentare/Anmerkungen an Resource Nachrichten an Newsgroup, Mailinglist, … Einem Daten-Prozess Daten (z.B. Formular) liefern Daten erweitern
- 31.
- 32.
- 33.
- 34. REST Verlinkung “Hypermedia as engineof the application state” (Dissertation of Fiedling)
- 35. REST - Zusammenfassung –Adressierbarkeit – Zustandslosigkeit – Operationen – Verlinkung
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42. Beispiel - BodyparsenJSON
- 43. Beispiel - Bodyparsen-XML
- 44. Beispiel - Bodyparsen-Form
- 45.
- 46.
- 47. Beispiel - POST-Request >POST /my/collection HTTP/1.1 > User-Agent: … > Host: www.myhost.de > Accept: */* > Content-Type: application/json > Authorization: … > Content-Length: 556 {name:”max”,surname:”mustermann”,...}
- 48. Beispiel - POST-Response >HTTP/1.1 201 Created > Server: … > Date: … > Content-Type: application/json; charset=utf-8 > Location: https://.../my/collection/sub/2 > Content-Length 1389 > ETag: ...
- 49. Beispiel - GET-Request >GET /my/collection HTTP/1.1 > User-Agent: … > Host: www.myhost.de > Accept: */* > Authorization: ...
- 50. Beispiel - GET-Response >HTTP/1.1 200 OK > Server: … > Date: … > Content-Type: text/html > Content-Length: 1111 > Last-Modiefied: … > ETag: ...
- 51. Beispiel - PUT-Request >PUT /my/Collection/sub/4 HTTP/1.1 > User-Agent: … > Host: www.myhost.de > Accept: */* > Content-Type: application/json > Authorisation: … > Content-Lenght: 161 {name:”marie”,...}
- 52. Beispiel - PUT-Response >HTTP/1.1 200 OK > Server: … > Date: … > Content-Type: application/json; charset=utf-8 > Content-Length: 4654 > ETag: ...
- 53. Beispiel - DELETE-Request >DELETE /my/collection/sub/5 HTTP/1.1 > User-Agent: … > Accept: */* > Authorization: ...
- 54. Beispiel - DELETEResponse >HTTP/1.1 204 No Content > Server: … > Date: …
- 55.
- 56.
- 57.
- 58. Quellen • BlogPost zum BeispielCode: http://www.lornajane.net/posts/2012/building-a-restful-php-server-understanding-the-request • Buch:“RESTful Webservice” v. Leonard Richardon & Sam Ruby • https://github.com/schmittjoh/JMSSerializerBundle.git • https://github.com/FriendsOfSymfony/FOSRestBundle.git • Blog zu Links: http://qafoo.com/blog/048_embedding_rest_entities.html • Link zu RestTalk von DrupalCon: http://www.youtube.com/watch?v=SSkZZLpaqdI
- 59.
- 60. LiveCoding FOSRestBundle -> Controllervom FOSREstBundle zeigen -> Beispiel Requests auf diesen
- 61.
Hinweis der Redaktion
- #2 {"49":"- eig. wie jeder Webseitenaufruf = GET-Request\n- VERB: GET\n- Resource: z.B Collection (ohne Id), bestimmte resource (mit id) -> CRUD-Sicht der Dinge\n- Accept-Header für die Antwort sind wichtig\n-> Angabe als Liste möglich \n-> hier der dümmste, der geht (IE)\n","38":"- warum?\n- Models können Resourcen repräsentieren\n- Views: content sensitive Ausgabe\n-> entscheiden wie die Repräsentation aussehen soll\n-> ausgehend vom Accept Header und dem was der Service kann\n-> Content-Type setzen,...\n- Controller: Logic => Methoden abbilden\n-> getAction($id), postAction($data,$format), putAction($data,$format),deleteAction($id)\n-> muss nicht immer alles an eine id gebunden sein\n","27":"- ähnlich wie GET\n- nur ohne Body\n-> also alle MetaInformationen die mit GET kommen würden\n","16":"Was ist hier anders?\n- Operationen = HTTP-Verben\n- Resourcen direkt in der URL (addressierbarkeit)\n- Methoden beschränkt\n- Resourcen eindeutig (URL, URI)\n-> jetzt endlich REST \n","5":"Vorstellen wie einen Brief:\n- Adresse - URI\n- Adresszusätze - Metadaten im HTTP-Header\n- Informationen zum Absender\n-> im sog. HTTP-Header\n","33":"- zum Löschen einer Resource\n- Identifizierung über URI\n","22":"Mögliche Header für einen Response:\n- der content-type der Antwort im Body\n- die mögliche Sprache der Antwort\n","50":"Erfolg: StatusCode 200 OK\n- Content-Type\n-> hier html, wie üblich für ein GET-Request auf bspw. einer Webseite\n- Content-Length\nCaching-Data:\n-> Last-Modified und ETag\n-> beispielsweise für nächsten Request, mitsenden -> 304 Not Modified -> cool muss nix neu laden\nBody mit den Daten im angegebenen Format (XML, JSON, HTML, …)\n-> hier können dann Hypermedia-Informationen angegeben werden\n-> aktuelle url, url von Subresourcen, oder userdata\n-> Client kann eigenständig navigieren\n","39":"- Abbildung Request<->Response Zyklus \n- Client macht Request -> alle Informatioen aus Request-Object\n- Server bereitet Antwort mit Views vor: Response-Object\n- Request-Object kann OOP Wrapper für $_SERVER sein -> nicht schlimm\n","28":"- liefert mögliche Operationen auf Resource\n- kann mit/ohne Authenfication unterschiedlich sein\n","17":"- Möglichkeit Resource anzuwählen\n- eindeutig \n- Siegeszug des Web: Seiten = Resourcen adressierbar\n- z.B. www.google.de -> aufschreiben, weitergeben, verlinken auf andere Resourcen\n- eine Adresse kann nur eine Resource bereitstellen (URI = UniformResourceIdentifier)\n- eine Resource kann aber unter mehren Adressen erreichbar sein (canonical, duplicate)\n","6":"Z1: Adresse \n- Operation = HTTP-Verb (GET später noch erklärt) -> GET die meist verwendete üblichste\n- URI (auf Host aufgerufen) \n- Übertragungsprotokol (HyperTextTransferProtocol in v1.1)\nZ2-7: weitere Meta-Informationen\n- gewünschtes Format für die Antwort\n- gewünschte Sprache für die Antwort\n-> weitere Erklärung später (Repräsentation)\n- caching Eigennschaften\n- Host, der angesprochen wird\n- der User-Agent, der die Anfrage sendet\n-> viele weitere Möglich\n-> einige werden per Default mit gesendet, andere kann/sollte man gezielt für Anfragen setzen\n","56":"- REST-Bundle im Context von Symfony\n-> Routing durch Symfony gegeben\n-> Controller als RestController zum extenden\n-> Rückgabe von ResponseObject oder Daten zum rendern\n- dort README.md lesen\n- Doku vorhanden\n- \n","45":"status($code) \n-> setzt den Status \n-> nur nummer nötig den Text setzt ich aus Array\nsetHeader($val)\n-> mehr ein addHeader() \n-> einfache Strings in eine array bauen \n-> werden später einfach über header(); ausgegeben\n->send()\n-> switch der type sentisitiv den output vorbereitet\n-> jeder Fall ruft weitere methode auf, die dann die Daten ausgibt\n-setData($data)\n-> the data to render with an template\nsetFormat($format)\n-> wenn ich aus dem ProgrammCode heraus unabhängig den Content-Type setzen will\nredirect($url)\n-> setzt ein location header und setzt, wenn was drin ist den status\n","34":"- Was wäre Web ohne Links?\n- Webseiten (=Resourcen) beinhalten Links \n-> andere Seiten (=Resourcen) erreichbar\n- ebenso in REST möglich \n-> noch nicht so tief drin, aber:\n- durch: Hypermedia \n-> HTML, XML als Links zu anderen Resourcen \n-> “MultimediaLinks” \n-> verschiedene Resourcen, nicht nur Text (Hypertext)\n-> Vorschläge für den Pfad durch den sog. Application State\nRelative Resourcen angegeben\n","23":"Informationen über Repräsention auch in der URI möglich\n-> Ansichtssache\n- viele Informationen in URI als Vorsatz\n- Struktur nicht verlieren\n","12":"- Client muss WebService mitteilen was zu tun ist\n- nur Daten abrufen\n- neues Item anlegen\n- bestehende Resource ergänzen\n","1":"Schon wieder ein REST Talk?\n- Auswerten der Umfrage auf Xing, festellen wie Wissenstand ist\n","51":"Eigentlich wie POST\n- Resource muss genau bekannt sein (also deren Adresse)\n-> vorher GET Request um die Daten zu haben -> Verändern\n- Content-Type/Content-Length weil Daten im Body vorhanden\n- Body mit den Daten\n","40":"- url auslesen (Request-Object)\n- muss sehr ausgeklügelt sein\n- Controller für Resource aufrufen\n","29":"- am meisten “missverstandenes” HTTP-Verb\n- als Standart für SOAP/XML-RPC apis alles ist POST an eine bestimmte uri\n","18":"- Zustandslosigkeit (engl. schöner)\n- Grundwert von HTTP\n- jeder Request für sich abgeschlossen\n- keine Seitenefekte möglich\n- Reihenfolge unabhängig (Back-Button geht nicht -> nicht Stateless)\n- eigentlich Web so aufgebaut\n- man muss effektiv etwas dafür tun um dagegen zu verstoßen (Sessions)\n","7":"Z1: Protokol + Status der Antwort als Headline\n-> viele verschiedene Statuscodes \n-> Liste Wikipedia\n- Typ der Verbindung\n- Content-Type, das Format der Daten im Body -> zum parsen nötig\n- Datum\n- letzte Änderung -> Caching\n- Content-Length: Größe der Antwort, z.B. auch beim Download\n","57":"- POST,PUT Daten in Objekte umwandeln\n- Ausgaben von GET content sensitive erstellen\n","46":"selbst erklärend:\n-> content-type setzen\n-> restliche header ausgeben\n-> daten rendern ausgeben \n-> html per twig, xml per simpleXML (noch) sonst json_encode\n","24":"- gibt noch weitere, aber diese sollen reichen\n- Beispiele folgen\n","2":"1.)\n- Definition\n- Vokalbeln\n- Wdh. HTTP Basics\n2.)\n- Beispiel nach dem Vorbild von Lorna Jane \n- eigene Entwürfe\n3.)\n- SymfonyBundle\n- zusammen mit dem JMSSerializerBundle\n","52":"Unterscheidung von POST\nErfolg: StatusCode 200 OK\n-> man erhält die selbe Instanz der Resource zurück\n-> Content-Type/Content-Length nötig\n","41":"post() -> einfach nur ein OOP Wrapper für $_POST \nget() -> einfach nur ein OOP Wrapper für $_GET\ngetHeader(), kann sowohl einzelnes Header d. Request zurück liefern als auch array aus allen\ngetVerb() liefert das Verb, Achtung: es gibt Clients (Backbone.js), die Verben per Method_Override schicken\ngetAcceptFormat() -> dummer Name, aber ließt gesondert den Accept-Header aus -> für die Response sinnvoll\ngetContentFormat() -> für das Parsing des Bodies -> Content-Type sehr wichtig\ngetData() -> parst die im Body gesendeten Daten anhand des Content-Type \n","30":"- aus RFC 2616 HTTP-Standart\n-> wenig mit $_POST zu tun (ebenso für $_GET)\n- wirkliche POST-Daten sogar: aus dem Body des Requests auslesen!\n- Wichtig: Body wird gesendet -> Content-Type+Content-Length senden!\n","19":"- Untescheidung nötig\n- Nutzer kann in gewissen Status in der Application haben\nz.B Google Unterseite 5 nach Suche auf\n- interessiert die Resource (Liste an Suchergebnissen) erst einmal wenig \n- Service muss aber unterschiedliche Nutzer in unterschiedlichen Stati unterscheiden können\nz.B. google api (alt) mit max queries: \n- Nutzer A hat 999 Queries gesendet, bekommt noch eine, danach 402 Payment Required\n- Nutzer B hat 400 Queries gesendet, bekommt noch länger Ergebnis\n-> Probleme bei Load Balancern = Scaleability\nmit Statelesness nur Problemenatisch wenn ich Resource auf Cluster splitten muss\n","8":"StatusCodes als Headlines -> erste Info, die man sieht\n1 - manchmal nötig, da sonst Clients in Timeout gehen (noch nie verwendet)\n2 - Häufig: 200 OK \n-> alles mit 2 ist gut\n3:\n-> alles mit 3 heißt ja, aber…\n301 Moved Permanently\n304 Not Modified \n- header(“location: /path”); -> 302 Moved Temporary -> header(“HTTP/1.1 301); vorher nötig!\n4:\n-> Fehler im Request\n400 Bad Request \n404 Not Found (Anfrage nach einer Resource, die nicht gefunden werden kann)\n5 - 504 Gateway Timeout\n","47":"- Verb: POST -> klar\n- URI mit Resource unter der eine SubResource angelegt werden soll\n-> also der collection\n- Content-Type der Daten, die im Bode mitgesendet werden müssen\n- Conten-Length\n- Accept, denn meist eine Antwort: komplette Repräsentation der Resource mit URI\n- Body die Daten\n","36":"Endlich bei der Bedeutung des Akronyms\n- es geht um Repräsentationen von Daten\n- deren Status wird ausgetauscht\n- aber zwischem wem?\n- Application State -> Resource State (POST, DELETE, PUT)\n-> application state wird übernommen\n-> soll übernommen werden\n- Resource State -> Application State (GET,HEAD, OPTIONS)\n-> man erhält den “aktuellen” Stand der Resource\n","25":"- keine Änderungen an der Resource\n- client erwartet keine SideEffekte\n- sog. “Sichere” Operationen\n","14":"- da sieht man nicht viel\n- Methode + Resource Inforamtion im Body\n- Verteter: XML-RPC -> Body im XML-Format \n","53":"- Verb: DELETE\n- URI: genaue Resource\n-> sehr einfach\n","31":"- zum Ändern einer Resource\n- resource muss direkt angesprochen werden\n- wichtig: vorher muss ein GET-Request passiert sein, damit man die Resource vor sich hat -> Ändern\n- Daten im Body mitsenden\n- Content-Type angeben -> Identifizierung des Body/der Daten\n- Anlegen einer Resource, wenn genaue Adresse bekannt\n","20":"- Resource nicht nur Daten\n- Darstellung/Aufbereitung der Daten oder Sprache des Inhalts\n-> Eine Resource verschiedenen Repräsentationen\n- Wie wählt man Repräsentation?\n","9":"sog. WebService\n- Softwareanwendung über Netzwerk für Maschine-Maschine-Interaktion (Wikipedia)\n- unsere Software meist Client \n- z.B. google api\n","48":"Erfolg: StatusCode 201 Created\nContent-Type/Content-Length -> klar\nLocation: URI der neuen Resource = Redirect auf die neue Resource -> man hat die Daten\n","37":"- nun ein kleines Beispiel\n- kein vollständiger Code\n-> nach zu lesen in Blog-Article von Lorna Jane\n","26":"- Informationen zu einer Resource erhalten\n- Daten werden im Body (mit content-type, content-length) geliefert\n","15":"SOAP:\n- Spezialisierung von XML-RPC\n-> Body (mit Method und Resource Information) in SOAP- Envelope eingebettet\nMethoden:\n- unbestimmt viele\n- durch Doko festgehalten\n- GET/POST -> unterschiedlich\n","4":"- egal ob Browser, Curl oder sonstiger Client\n-> alles beginnt mit dem sog. Request v. Client\n-> Antwort vom Server: Response\nBeispiel:\n- Browser (Client) fordert Inhalt einer Seite an: Request\n- Server bearbeitet diesen,\n- gibt eine HTML-Seite aus: Response\n","54":"Erfolg: StatusCode: 204 No Content\n- resource wurde gelöscht\n-> da gibt es Nichts zurück zu sende, was denn auch???\n","32":"- zum Anlegen einer Resource\n- unter einer Resource anlegen\n- wo man die neue uri nicht kennt\n-> Body/Daten identifizieren\n","21":"Mögliche Header für einen Request:\n- in welchem Format will ich die Resource haben\n- in welche Sprache\n- auch Authenfication spielt eine Rolle (siehe OPTIONS)\n- Metadaten \n","10":"- geht um Erhalten, Verändern oder anlegen von Daten bzw. Informationen\n- viele Dinge können Resourcen sein\n- nicht nur sog. CRUD-Items \n- nicht nur Abbildung von SQL-Schemata\n- auch als “Scoping Information” bezeichnet\n"}