Rest

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"}