REST teori og praksis; REST in theory and practice

Editor's Notes

• #2: \n
• #3: Hvor mange tror dette?\nDet stemmer ikke. REST er ikke det samme som HTTP, men det er vanlig å bruke HTTP for å oppnå en RESTful arktitektur. Jeg kommer til å bruke HTTP som hovedbestanddel i denne presentasjonen.\n
• #4: Hvor mange tror dette?\nDet stemmer ikke. REST er ikke det samme som HTTP, men det er vanlig å bruke HTTP for å oppnå en RESTful arktitektur. Jeg kommer til å bruke HTTP som hovedbestanddel i denne presentasjonen.\n
• #5: \n
• #6: Først litt historikk: Dr. Roy Fielding var en av de som var med å utvikle HTTP, og i denne prosessen skrev han også doktoravhandlingen sin om arkitektoniske stiler. \n
• #7: Denne ble utgitt i 2000. Han beskriver arkitektoniske stiler som et sett med begrensninger for å oppnå visse kvaliteter eller egenskaper i en konkret arkitektur. REST er eksempelet i dette doktoravhandlingen. For en doktoravhandling er den forbausende lettlest, og jeg anbefaler alle å gjøre dette. Linken til denne vil stå på slutten av teoridelen. Det er med andre ord mulig å kunne bruke denne doktoravhandlingen til mye mer enn bare for REST som eksempelform. Det er mye fornuftig skrevet her.\n
• #8: Den viktigste designoperasjonen i en restful arkitektur er design av dataformater, eller hypermedia formater. Jeg kommer tilbake til dette litt senere. Et av målene til REST er å frikoble data mer fra serveren / klienten, og heller la alle ting bli oppdaget ved hjelp av hypertekst.\n
• #9: Denne begrensningen er relativt selvforklarende. REST er Request/response basert. Hovedforskjellen i forhold til en RPC basert akritektur, er at serveren har mye mer makt i forholdet her. Dette gjelder blant annet statelessness i kommunikasjon, noe som vi skal komme tilbake til senere. Klientene har et mye større ansvar i å holde på kontekst i forhold til det de er ute etter på serveren. Klienten må vite hvorfor den gjør de valgene som trengs. Kontekst er utrolig viktig.\n
• #10: Det unforme interfacet er bygget opp i flere deler, jeg vil gå igjennom de hver for seg.\n
• #11: Roy Fielding satt også i komiteen som definerte URI\nURI er et superset av URL og URN Eksempler følger på neste slide.\n\nRessurser er alle ting som kan modelleres. Feks en Bil, en aktikkel, en annonse, en event osv. Det er viktig å tenke på ressurser som substantiv, men der er unntak der også... en ressurs kan ha flere urier.\n
• #12: \n
• #13: \n
• #14: \n
• #15: \n
• #16: \n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: En representasjon er alt som blir servert i bodyen til en melding.\n
• #22: HTML. Rendert. <click> Eller amazon kunne vel sett slik ut? ehm, kanskje ikke helt, men dere ser poenget.\n
• #23: HTML. Rendert. <click> Eller amazon kunne vel sett slik ut? ehm, kanskje ikke helt, men dere ser poenget.\n
• #24: Dette er et Atom feed som dere sikkert ser.\n
• #25: Dette er et format som heter collection+json, jeg kommer tilbake til dette senere.\n
• #26: Dette betyr at meldingen inneholder alle ting som skal gjøre den forståelig for en klient. \n\nSelf-descriptive betyr metadata + data. Man skal kunne inspisere headerene og forstå hvordan kroppen på meldingen skal prosesseres basert på headeren + status kode i HTTP. Content-Type headeren betyr hva innholdet er. \nAkkurat dette er en litt vanskelig bit av REST. Det har med noe som man kaller ‘visiblitity’ eller synlighet. Om man bruker et standardformat, kan man lettere utnytte nettverksinfrastruktur som forstår disse formatene. Feks om man bruker HTML kan google webaccelerator gjøre dns oppslag på forhånd osv.\n\nMark Nottingham sier det ganske bra: “I want to follow my nose when consuming an API”. Dette betyr at dokumentasjonen må være lett tilgjengelig, gjerne linket til i meldingen.\n\nDersom man serverer noe som er for generisk, feks application/json eller application/xml er ikke meldingen lenger self-descriptive, og systemet kan ikke gjøre noe med meldingen uten out-of-band informasjon. Dette øker koblingen mellom klient og tjener, og er en av de tingene som REST prøver å unngå. Koblingen blir bibliotekstyrt i forhold til nettverksstyrt, dette er uheldig\n
• #27: Hver request skal inneholde alt som skal til for å kunne tilfredstille serveren. Dette betyr at serveren ikke skal ha noen form for “midlertidig” informasjon om hvilke klienter som er koblet til.\nAuthentication og slikt er et eget kapittel, som jeg skal prøve å få behandlet i den praktiske biten.\n
• #28: Dette er en av de viktigste og mest misforståtte bitene av REST, og det krever nesten et eget foredrag. Hovedsaklig betyr det at man bruker hypertekst les; linker, skjemaer mm., for å kunne gjøre valg som man fikk i den forrige responsen fra serveren. Et “skjermbilde” på en klient kan være bygd opp av MANGE ressurser. Hvordan klienten velger å vise frem ting er out-of-scope for serveren sin del. Serveren sin interaksjon slutter når den har levert fra seg responsen.\n
• #29: Dette er en av de viktigste og mest misforståtte bitene av REST, og det krever nesten et eget foredrag. Hovedsaklig betyr det at man bruker hypertekst les; linker, skjemaer mm., for å kunne gjøre valg som man fikk i den forrige responsen fra serveren. Et “skjermbilde” på en klient kan være bygd opp av MANGE ressurser. Hvordan klienten velger å vise frem ting er out-of-scope for serveren sin del. Serveren sin interaksjon slutter når den har levert fra seg responsen.\n
• #30: Dette er en av de viktigste og mest misforståtte bitene av REST, og det krever nesten et eget foredrag. Hovedsaklig betyr det at man bruker hypertekst les; linker, skjemaer mm., for å kunne gjøre valg som man fikk i den forrige responsen fra serveren. Et “skjermbilde” på en klient kan være bygd opp av MANGE ressurser. Hvordan klienten velger å vise frem ting er out-of-scope for serveren sin del. Serveren sin interaksjon slutter når den har levert fra seg responsen.\n
• #31: Dette er en av de viktigste og mest misforståtte bitene av REST, og det krever nesten et eget foredrag. Hovedsaklig betyr det at man bruker hypertekst les; linker, skjemaer mm., for å kunne gjøre valg som man fikk i den forrige responsen fra serveren. Et “skjermbilde” på en klient kan være bygd opp av MANGE ressurser. Hvordan klienten velger å vise frem ting er out-of-scope for serveren sin del. Serveren sin interaksjon slutter når den har levert fra seg responsen.\n
• #32: Dette er en av de viktigste og mest misforståtte bitene av REST, og det krever nesten et eget foredrag. Hovedsaklig betyr det at man bruker hypertekst les; linker, skjemaer mm., for å kunne gjøre valg som man fikk i den forrige responsen fra serveren. Et “skjermbilde” på en klient kan være bygd opp av MANGE ressurser. Hvordan klienten velger å vise frem ting er out-of-scope for serveren sin del. Serveren sin interaksjon slutter når den har levert fra seg responsen.\n
• #33: Dette betyr at arkitekturen skal være slik at man kan sette noe man kaller en “intermediary” på forskjellige deler i nettverket, slik at man feks kan redusere latens, feks med caching (kommer tilbake til det), DNS pre-lookup, Bildeskalering osv.\n
• #34: Dette er annen viktig bit av REST. Hver klient som bruker REST bør ha en form for klientcaching. Dette for å unngå å måtte gå til serveren med hver eneste request. Serveren skal sende metadata som forteller hver komponent i nettverket om hvor lenge de kan cache den gjeldende responsen.\n
• #35: Dette er typisk javascript. Dette er for å kunne servere generiske hypermedia formater, som kan igjen få ny funksjonalitet.\nMan kan i teorien også gi andre scriptspråk basert på hvilken klienttype man er; feks python script til python klienter, eller scalascript til Scala klienter. Dette er dog ikke mulig i dagens HTTP, da det mangler content negotiation på “embedded ressurser”. Det er, dog, en interessant tanke.\n
• #36: \n
• #37: \n
• #38: \n
• #39: \n
• #40: Dette er noen faktorer utviklet av Mike Amundsen, som har skrevet boken som jeg loddet ut i sta.\n
• #41: \n
• #42: \n
• #43: Det er også mulig å bruke REST med andre protokoller, men dette er den mest vanlige kombinasjonen. Hypermedia MÅ man ha for å kunne kalle det REST.\n
• #44: \n
• #45: \n
• #46: Vi skal lage et system som er et register over Events, sesjoner, og kontakter. En Event har en dato, og navn. En session har et abstract + noe metadata. En kontakt er en person av et slag. En sesjon kan ha flere speakers, som er en “embedded” kontakt. Dersom det er noen javaBin folk her, så vet de kanskje hvilket system det er :)\n
• #47: Dette er et forsøk på å vise sammenhengen mellom entitetene.\n
• #48: Disse ressursene og navnene er viktige for en utvikler som skal implementere serveren. En klient skal aldri vite hvordan disse urlene skal konstrueres, med mindre man har blitt fortalt det av serveren (URL Templating). Der er flere også, som kan kalles skjulte ressurser, men vi kommer tilbake til de etterhvert.\n
• #49: Her finnes det veldig mange muligheter; Noen er mer restfulle enn andre. Jeg vil gå igjennom et utvalg her.\n
• #50: Denne er jo ganske straight forward. Man skriver javaobjektene direkte til outputstream. Noen som kan fortelle meg hva som ikke er bra med dette? SerialVersionUUID +++ Det gjør det veldig vanskelig å vedlikeholde server og klient på forskjellige stadier, det gir kobling, noe som REST prøver å unngå. Hvilke av H-Factorene finnes i serialiserte javaobjekter? Ingen. I den første versjonen av EMS som vi lagde gjorde vi nettopp dette; Dette førte til at vi måtte fikse klientene hver gang vi la til et nytt felt i domenemodellen. Dette skalerer åpenbart ikke når man får flere klienter, og sannsynligvis har man ikke kontroll på de heller.\n
• #51: Vi kan feks bruke JAXB eller XStream og serialisere domenemodellen vår direkte? Hva gir dette oss? Hvordan er det med veldikeholdbarhet? Mange inkluderer <atom:link> i xml outputen, dette gjør det litt bedre, men dersom dette fortsatt blir servert som application/xml så kan jeg ikke ta noen beslutninger på dette.\n
• #52: \n
• #53: En direkteserialisering til JSON er også mulig; Hvilke HFaktorer innehoder JSON? Ingen. Hvordan kan vi da oppdage de operasjonene som er mulig å gjøre? vi kan ikke det uten sterk kjennskap til hvordan serveren serialiserer objektene. Dette er greit når man har full kontroll mellom server/klient, ikke så greit når man skalerer over det.\n
• #54: \n
• #55: Dette er en farbar vei. Nå kan vi bestemme nøyaktig hvordan dataformatet skal lages. Dette har jeg gjort flere ganger, og kan godt være en løsning når man ikke finner noe som passer til det man skal gjøre. Lager man et eget format kan det hjelpe konsumenter, om man registrerer det med IANA (The internet assigned numbers authority).\n
• #56: \n
• #57: \n
• #58: Dette er en ny mediatype laget av Mike Amundsen, som også jeg har hjulpet til med å lage. Den ligner litt på Atom i forhold til det meste er modellert i kontekst av collections + items. Denne har flere av HFaktorene, som blant annet er Templated queries, Embedded links, outgoing links og idempotent updates.\n
• #59: \n
• #60: Dette er en ganske vanlig måte å kunne utrykke hypermedia. Her finnes flere av HFaktorene, noe som man kan se utfra siden til Mike. Atom er bygget for å være extensible, så man kan gjøre mye med formatet dersom det ikke passer helt.\n
• #61: \n
• #62: Man kan også bruke HTML for også å utrykke data. Se gjerne referansene på slutten av presentasjonen for å finne noen eksempler på dette.\n
• #63: Hvordan gjør jeg ting med det jeg får tilbake? Hvordan vet jeg hvor jeg skal POSTe en ny sesjon? hvordan oppdaterer jeg?\n\nI Hovedsak håper jeg at jeg har vist hvordan dette gjøres ved at man ser på Hfaktorene for det gitte formatet man har.\n\nMan må også dokumentere hvordan man gjør operasjoner, feks hvilke relasjonstyper som er tilgjengelige og hva disse betyr. Helst bør man bruke de som allerede er registrert, link vil være i referansene. Eller om mediaformatet har et eget register, bør man bruke det.\n
• #64: Bruker man AtomPub så har man mulighet til å gjøre det man gjøre en HTTP POST til den ressursen som er designert collection ressursen.\n\nI collection+json kan man bruke template som følger med en collection ressurs til å lage en ny.\n\nI HTML fyller man inn et skjema.\n
• #65: Fører til en HTTP PUT de fleste tilfeller\n\nI Atom: PUT av ressursen som er markert som “edit”.\n\nI Collection+json: Transformer “data” til en template og PUT den tilbake\n\nI HTML: Enten code-on-demand for PUT støtte, eller et annet skjema med HTTP POST\n\nStatuskoder er typisk: 204 No Content eller 200 OK med full body og en Content-Location med samme href. Dette gjør man for at cacher skal oppføre seg korrekt.\n
• #66: Dette er en interessant greie:\n * Man kan gjøre dete ved HTTP PUT til en sub-resource av den tingen man oppdaterer. Dette er et problem for caching, pga en vet ikke hvilke ressurser som skal invalideres. Kan løses ved kort cache-tid + validering eller ved at man bruker cache-channels.\n\n* Man kan bruke HTTP Patch.\nMan kan detektere at en ressurs støtter partial updates ved at man ser på “Accept-Patch:” conneg headeren. Dersom denne finnes, så kan systemet gjøre partial updates. Jeg vet desverre ikke om noen mediatyper som i dag støtter partial-updates.\n
• #67: HTTP DELETE støtte finnes ikke i alle formater\n\nI Atom vil det være det samme som for PUT. HTTP DELETE for ressursen som er markert som “edit”.\n\nI Collection+json, HTTP DELETE til “href” i en Item\n\nI HTML: her må man bruke HTTP POST i en form, eller HTTP DELETE via code-on-demand\n\nStatuskoder er viktige. Man kan få tilbake 204 No Content på første, eller 404 om den ikke finnes. Man kan også få 410 GONE om man allerede har slettet.\n
• #68: Søk er en interessant greie, der finnes noen kandidater her også:\n\n - Opensearch + Atom|RSS2.0\n - HTML get forms + HTML resultat\n - Collection+JSON Querys\n
• #69: Når en sesjon er godkjent av programkomiteen skal denne publiseres.\nDette kan man gjøre ved enten:\n * Partial update på published.\n * Lagre sesjonen på nytt med “published” flagget satt.\n * en egen publiseringstjeneste:\n ** en eller flere URLer som skal publiseres.\n *** POST en text/url-list med alle som skal publiseres\n *** denne tjenesten må oppdages. feks via en link med rel=”publish”\n ** HTML form med et enkelt tekstarea hvor man fyller inn en linje pr url.\n\n
• #70: Så var det denne. Her finnes det ganske mange forskjellige løsninger. De fleste er ganske greie å ha med å gjøre.\n
• #71: Dette er iogforseg greit nok. Problemet er her at man sender passordet over tråden noe som aldri er bra.\n
• #72: Dette er mye sikrere enn HTTP basic.\n
• #73: Her har man forskjellige protokoller:\nDe største er:\n * OAuth\n * OpenID\n
• #74: En veldig spennende spec som utvikles av W3C for øyeblikket.\nBasert på PKI og RDF; Les FOAF (friend of a friend)\n
• #75: En interessant spec fra Mozilla labs.\n
• #76: En ganske interessant greie som Google har laget. Krever Google konto + SSL\n
• #77: Dette er det veldig mange som gjør. Det er desverre de skjelden bygger på WWW-Authenticate med venner. Prøv å unngå dette.\n
• #78: Et sitat hentet fra http-auth mailinglisten. Jeg har en mistanke om at det er en spøk ;)\n
• #79: Går typisk under “roll-your-own”. Det er dog efforts fra IETF for å fikse opp i dette. Det går kanskje an å lære noe fra \n
• #80: \n
• #81: \n