Webbteknik II Föreläsning 5 Restless farewell
HTTP Request HTTP verbs (methods): GET, POST, HEAD, DELETE, PUT, OPTIONS, TRACE, CONNECT http://www.w3.org/protocols/rfc2616/rfc2616-sec9.html variable=value&variable2=value2 http://blogs.plexibus.com/2009/01/15/rest-esting-with-curl/
HTTP Request Accept: MIME-typer, talar om vilket dataformat du vill ha tillbaka Host: Namn på servern som vi anropar, används för virtual hosting Cookie: Information om webbkakor User-agent: Webbläsare, operativsystem, information om klienten Referer: Anger URI till resursen som gav adressen till detta request (hämta bilder, script...) Connection: Hur ska anslutningen vara? Keep-Alive, Close Cache-control: Web Cache
HTTP Response Header Status Code: 1xx - Informational, 2xx - Success, 3xx - Redirection, 4xx - Client Error, 5xx - Server Error http://www.w3.org/protocols/rfc2616/rfc2616-sec10.html Body - HTML
Web Cacheing Teknik för att spara kopior av ett response för att på detta sätt använda kopian vid ett request Web Cache - Någonstans mellan webbserver och klient Snabbare svar Minska traffik
Cacheing Browser Cache Webbläsaren sköter cache, back-button Proxy Cache Hanterar flera användare, ISPs, Shared cache Gateway Cache Verktyg för byggande av skalbara, större webbplatser, lastbalansering, CDNs (Content delivery networks)
Ingen cachning sker GET Cache handler header: no-cache GET https
Cachning sker GET Cache handler Expires: 2041-01-01 Kopia av Response max-age: 3600 GET Modified: 2006-01-01
Validering av utgången data GET Cache handler Modified? Expired: 40 seconds ago NO Kopia av Response GET Om koppling mellan cache och server inte fungerar kan cache presenteras
Hur gör man? Meta-taggar i HTML? Få proxies tolkar HTML-koden när det kommer till cachning! Ingen bra idé alltså.
HTTP Headers - Expires HTTP/1.0 Sätter en tidpunkt (HTTP -Time) då kopian inte gäller längre Lång tid på t.ex. statiska filer (sätts på webbservern -.htaccess, web.config) Webbserverns klocka måste funka! Lätt att glömma att man satt en tid
Cache-Control HTTP Headers no-store: Spara ingen kopia HTTP/1.1 no-cache: Du får spara men aldrig skicka en sparad kopia till klient public: Var så god att cache:a private: Response-meddelandet är privat, webbläsare får cacha, inte proxies max-age: Hur länge ska kopian finnas (i sekunder) s-maxage: Som ovan men endast för shared caches Last-Modified: Visar tidpunkt för senast modifikation av data ETag: Unikt värde för cache:ad kopia must-revalidate: Måste undersöka om det finns ny data enligt den information som finns i HTTPheadern If-Modified-Since: Fråga efter en resurs om den uppdaterats (304 - Not modified) If-None-Match: Som ovan men för ETag
Självstudie
Hur gör jag? Cachning kan styras både från webbserverns inställningar och från serverscript-kod http://httpd.apache.org/docs/2.0/mod/mod_headers.html http://httpd.apache.org/docs/2.0/mod/mod_expires.html http://se.php.net/manual/en/function.header.php
Att tänka på Genomtänkta URL:er är viktigt! Inte flera länkar till samma resurser Cache:a statiska filer som inte ändras ofta (bilder m.m.) Minimera användning av SSL/HTTPS Tänk efter när du sätter max-age och liknande attribut - Hur ofta uppdateras resursen Låta script dumpa statiska sidor när de ändras och förlita dig på validering (Last-Modified, 304 Not Modified)
Mer tips Använd inte POST i onödan - Cache bör bara användas på GET Kör du en webbsite med klustrad lösning - Undvik ETag Använd CDNs! (Content delivery Network)
Persistent Connections I tidiga versioner öppnade varje anrop en TCP-anslutning Anrop av bilder, script m.m. gjorde att man utvecklade persistent connections till HTTP/1.1 Håller kopplingen öppen för några sekunder - Kan skicka flera anrop på samma Keep-Alive: 300 Connection: keep-alive Connection: close
Svagheter/styrkor i HTTP Design för client - server med request - response Stateless Säkerheten? HTTPS (SSL)
Varför använder vi inte HTTPs headerinformation mer?
REST Representational State Transfer Roy Fielding, 2000 Architectural styles and the design of networked-based architecture http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://roy.gbiv.com/ Ingen standard Riktlinjer för webbapplikationers/api:ers arkitektur Being RESTful REST over HTTP
Every thing is a Resource A resource can be any meningsful concept that may be adressed http://www.mysite.com/users En resurs med en lista över alla användare http://www.mysite.com/users/{id} En resurs med en specifik användare
Every resource must have a unique ID URI - Uniform Resource Identifier http://www.mysite.com/users En resurs med en lista över alla användare http://www.mysite.com/users/{id} En resurs med en specifik användare Addressability - Cacheing
Use standard methods Request http://www.mysite.com/users GET Hämta alla användare http://www.mysite.com/users/{id} GET Hämta en viss användare http://www.mysite.com/users/{id} POST Lägg till en ny användare http://www.mysite.com/users/{id} PUT Uppdatera en användare http://www.mysite.com/users/{id} DELETE Ta bort en användare Response http://www.mysite.com/users GET Hämta alla användare 200 OK Samma interface på alla resurser, lätt att förstå!
Every resource is in a state GET, HEAD - Ändrar inte resursens state (safe methods) POST, PUT, DELETE - Ändrar resursens state (unsafe methods)
One resource - Multiple representations http://www.mysite.com/users/{id} Accept: application/xml Jag vill ha det i XML http://www.mysite.com/users/{id} Accept: text/x-vcard Jag vill ha vcard-format
Hypermedia Hypermedia as the engine of application state (HATEOAS) Länkningar, inom egna eller till annan applikation, Självförklarande Länkarna flyttar applikationen till en annan State Hyperlinking is what makes the Web the Web
Communicate statelessly Stateless = ta hand om många förfrågningar, cachningsbart Klientapplikationen får gärna ha olika states Undvik cookies, sessions = Problem?
Många snackar om REST over HTTP Trots att man: 1. Kör allt via GET 2. Kör allt via POST 3. Ignorerar caching 4. Ignorerar response codes 5. Överanvänder cookies 6. Tänker inte på hypermedia 7. Ignorerar MIME-typer 8. Struntar i att vara självbeskrivande
Men...Hur? How to get a cup of coffee? http://www.infoq.com/articles/webber-rest-workflow http://restinpractice.com
Att tänka på när man bygger HTML Forms har bara stöd för GET och POST URL Rewriting -.htaccess, web.config http://www.mysite.com/user/{id} Det kommer finnas demo-filmer inför laborationen
Slutord om REST En high-level arkitektur - Kan bli abstrakt REST over HTTP!= REST En webben (HTTP) kan ses som en REST-implementation Bör man vara REST-afarian?