Representational state transfer

Representational state transfer (REST, direkte oversatt: «representativ tilstandsoverføring») er en stil som er utformet for å veilede design og utvikling av programvareteknisk arkitektur for verdensveven. REST definerer en rekke begrensninger for hvordan arkitekturen til systemer for hypermedia som blir distribuert i internettskala (som for eksempel verdensveven) bør oppføre seg. REST-stilen for arkitektur vektlegger skalerbarhet på sammenkoblingen mellom komponenter, énsartede grensesnitt, uavhengig utrulling (deployering) av komponenter, og etablering av en lagdelt arkitektur for å tilrettelegge for hurtigbufring (caching) av komponenter for å redusere oppfattet ventetid hos brukere, håndheve sikkerhet og kapsle inn «legacy-systemer».^[1]

Etymologi

Begrepet representational state transfer ble definert i 2000 av Roy Fielding i sin doktorgradsavhandling.^[1] Begrepet er ment å gi et bilde på hvordan en veldesignet vevapplikasjon oppfører seg, i form av et nettverk av vevressurser (en virtuell endelig tilstandsmaskin) hvor brukeren avanserer gjennom applikasjonen ved å velge lenker (for eksempel http://www.eksempel.no/artikler/21), hvilket resulterer i at neste ressursrepresentasjon (neste applikasjonstilstand) overføres til klienten og gjengis for brukeren.

Anvendelsesområder

REST er blitt brukt på tvers av hele programvareindustrien, og særlig blitt akseptert som retningslinje for å skape tilstandsløse og pålitelige vevprogrammeringsgrensesnitt (web-API). Et vev-API som følger begrensningene satt av REST kalles uformelt RESTful. Slike grensesnitt er ofte løst basert på HTTP-metoder for å aksessere ressurser via URL-enkodede parametre, og bruk av JSON eller XML for å overføre data.

Ressurser på verdensveven ble opprinnelig definert som dokumenter eller filer identifisert ved sine URL-adresser. Idag er definisjonen mer generisk og abstrakt, og inkluderer alle ting, entiteter eller handlinger som kan identifiseres, navngis, adresseres, håndteres eller utføres på noen som helst måte på veven. Med en RESTful vevtjeneste vil forespørsler til ressursens URI gi et svar med et innhold (en nyttelast) formatert i HTML, XML, JSON eller et annet format. Svaret kan for eksempel bekrefte at tilstanden til ressursen har blitt endret. Svaret kan også omfatte hypertekstlenker til beslektede ressurser. HTTP er den vanligste protokollen for disse forespørslene og svarene. Eksempler på noen vanlige HTTP-metoder er GET, POST, PUT og DELETE.^[2] Ved å bruke en tilstandsløs protokoll og standardiserte operasjoner forsøker RESTful-systemer å gi rask ytelse, pålitelighet og evne til å vokse ved å gjenbruke komponenter som lar seg administrere og oppdatere uten å påvirke systemet i sin helhet, selv mens det kjører.

Formålet med REST er å få bedre ytelse, skalerbarhet, enkelhet, modifiserbarhet, synlighet, portabilitet og pålitelighet. Dette oppnås ved å følge REST-prinsipper som klient-tjenerarkitektur, tilstandsløshet, mellomlagring (cacheability), bruk av et lagdelt system, støtte for kode-på-forespørsel, og bruk av et enhetlig grensesnitt. Disse prinsippene må følges for at systemet skal kunne klassifiseres som RESTful.

Historie

Verdensveven begynte å bli dagligdags i 1993–1994, da nettsteder for generell bruk begynte å bli tilgjengelige.^[3] På den tiden var det bare en fragmentert beskrivelse av vevens arkitektur, og det var påtrykk i IT-bransjen om å bli enig om standarder for grensesnittprotokollene. Eksempelvis hadde flere eksperimentelle utvidelser blitt lagt til kommunikasjonsprotokollen (HTTP) for å støtte mellomtjenere, og flere utvidelser ble foreslått, men det var behov for en formell vevarkitektur for å evaluere effekten av disse endringene.^[4]^{[ufullstendig referanse]}

Arbeidsgrupper fra World Wide Web Consortium (W3C) og Internet Engineering Task Force (IETF) startet samarbeidet med å lage formelle beskrivelser av vevens tre hovedstandarder URI, HTTP og HTML. Roy Fielding var involvert i etableringen av disse standardene (mer konkret HTTP 1.0 og 1.1, og URI), og i løpet av de neste seks årene utviklet han REST som arkitekturstil, testet dens begrensninger på vevens protokollstandarder og brukte den som et middel for å definere arkitektoniske forbedringer og identifisere arkitektoniske uoverensstemmelser. I 2000 definerte Fielding REST i doktorgradsavhandlingen Architectural Styles and the Design of Network-based Software Architectures ved University of California, Irvine.

Som bakgrunn for REST identifiserte Fielding krav når en verdensomspennende nettverksbasert applikasjon skal opprettes, som for eksempel behovet for en lav inngangsterskel for at en skal bli tatt i bruk globalt. Han undersøkte flere eksisterende arkitekturstiler for nettverksbaserte applikasjoner, og identifiserte hvilke funksjoner som deles med andre stiler, som for eksempel mellomlagring og klient-/tjener-funksjoner, samt funksjoner som er unike for REST, som for eksempel konseptet om ressurser. Fielding prøvde både å kategorisere den eksisterende arkitekturen i eksisterende implementasjoner og å identifisere hvilke aspekter som bør anses som sentrale for atferds- og ytelseskrav til veven.

Det ligger i arkitekturstilers natur at de er uavhengige fra spesifikke implementasjoner, og mens REST ble skapt som en del av utviklingen av standarder for verdensveven, følger ikke nødvendigvis implementasjonen av verdensveven enhver begrensninge som er satt av REST-stilen. Uoverensstemmelser kan oppstå på grunn av uvitenhet eller forglemmelse, men ved hjelp av REST-stilen kan de identifiseres før de blir standardisert. For eksempel identifiserte Roy Fielding at innebygging av øktinformasjon i URIer var et brudd på begrensningene til REST som negativt kan påvirke delt hurtigbufring og tjenerskalerbarhet. HTTP-informasjonskapsler brøt også begrensningene i REST fordi de kan bli usynkronisert med nettleserens applikasjonstilstand, slik at de blir upålitelige. De inneholder også ugjennomsiktige data som kan være en utfordring for personvern og sikkerhet.

Arkitektoniske konsepter

REST-stilen er designet for nettverksbaserte applikasjoner, og da særlig klient/tjener-applikasjoner. Et viktigere poeng enn det er at den er designet for bruk på internettskala slik at koblingen mellom brukeragenten (user agent eller client) og opprinnelsestjeneren (origin server) må være så lettvektig (løs) som mulig for å lette storskala adopsjon. Dette oppnås ved å lage et abstraksjonslag på tjeneren ved å definere ressurser (resources) som innkapsler entieter (entities) (som for eksempel filer) på tjeneren, og så skjule de underliggende implementeringsdetaljene (filtjener, database, og så videre). Imidlertid er definisjonen enda mer generell enn det, og all informasjon som kan navngis kan være en ressurs, eksempelvis et bilde, en databasespørring, en temporal tjeneste (som for eksempel "dagens vær i Oslo"), eller til og med en samling av andre ressurser. Denne tilnærmingen gir størst interoperabilitet mellom klienter og tjenere i et langlivet internettskalert miljø som krysser organisatoriske (tillits-) grenser.

Klienter kan bare få tilgang til ressurser ved hjelp av URI-er. Med andre ord ber klienten om en ressurs ved hjelp av en URI, og tjeneren svarer med en representasjon av ressursen. En representasjon av en ressurs er et annet viktig konsept i REST, og for å sikre at svar kan tolkes av et bredest mulig antall klientapplikasjoner blir representasjonen av ressursen sendt i hypertekstformat. Dermed blir ressursen manipulert gjennom hypertekstrepresentasjoner overført i meldinger mellom klienter og tjenere.

Den sterke dekoblingen av klient og tjener sammen med tekstbasert overføring av informasjon ved hjelp av en uniform adresseringsprotokoll dannet et grunnlag for å møte kravene til internettet: Robusthet (anarkisk skalerbarhet), uavhengig distribusjon av komponenter, storkornet dataoverføring og en lav inngangsbarriere for innholdslesere, innholdsforfattere og utviklere.

Arkitektoniske egenskaper

Begrensningene i REST-stilen påvirker de følgende arkitektoniske egenskapene:^[1]^[5]

Ytelse i komponentinteraksjoner, hvilket kan være den dominerende faktoren i brukerens oppfattede ytelse og nettverkseffektivitet^[6]
Skalerbarhet som tillater støtte av et stort antall komponenter og interaksjoner mellom komponentene
Enkelhet gjennom et ensartet (uniformt) grensesnitt
Modifiserbarhet av komponenter for å møte endrede behov (selv når applikasjonen kjører)
Synlighet av kommunikasjon mellom komponenter av serviceagenter
Portabilitet av komponenter ved å flytte programkode med dataene
Pålitelighet i motstanden mot feil på systemnivå i nærvær av feil i komponenter, kontakter eller data^[6]

Arkitektoniske begrensninger

REST-stilen definerer seks veiledende begrensninger.^[5]^[7] Når disse begrensningene brukes på systemarkitekturen oppnår man ønskelige ikke-funksjonelle egenskaper som for eksempel ytelse, skalerbarhet, enkelhet, modifiserbarhet, synlighet, portabilitet og pålitelighet.^[1] Et system som samsvarer med noen eller alle disse begrensningene blir løst referert til som RESTful.

De formelle begrensningene for REST er som følger:

Klient/tjener-arkitektur

Designmønsteret for klient/tjener håndhever prinsippet om innkapsling (separation of concerns) som vil si at man skiller utfordringer i brukergrensesnitt fra utfordringer innen datalagring. Portabiliteten til brukergrensesnittet blir dermed forbedret. For eksempel med tanke på internett har det blitt utviklet en overflod av nettlesere for de fleste plattformer uten at man trenger kunnskap om tjenerimplementeringer. Separasjonen forenkler også tjenerkomponentene og forbedrer skalerbarheten, men en enda viktigere konsekvens er at det gjør at komponenter kan utvikle seg uavhengig (anarkisk skalerbarhet), hvilket er nødvendig i et miljø i internett-skala som involverer flere organisatoriske domener.

Tilstandsløshet

Innen databehandling er en tilstandsløs protokoll en kommunikasjonsprotokoll hvor ingen øktinformasjon beholdes av mottakeren (vanligvis en tjener). Relevante øktdata sendes til mottakeren av klienten på en slik måte at hver pakke med overført informasjon kan forstås isolert, uten kontekstinformasjon fra tidligere pakker i økten. Denne egenskapen til tilstandsløse protokoller gjør dem ideelle i applikasjoner med høyt volum, og øker ytelsen ved å fjerne tjenerbelastning forårsaket av oppbevaring av øktinformasjon.

Hurtiglager

I likhet med på veven kan klienter og mellomtjenere mellomlagre eller hurtiglagre (cache) svar. Svarene må, implisitt eller eksplisitt, definere seg som enten cacheable eller ikke-cacheable for å hindre klienter i å gi foreldede eller upassende data som svar på ytterligere forespørsler. Veldrevet mellomlagring eliminerer delvis eller helt enkelte klient/tjener-interaksjoner, hvilket forbedrer skalerbarheten og ytelsen ytterligere.

Lagdelt system

En klient kan vanligvis ikke vite om den er koblet direkte til slutttjeneren eller via en mellomtjener på veien. Dersom en mellomtjener eller lastbalanser er plassert mellom klienten og tjeneren skal det ikke påvirke kommunikasjonen deres, og det vil ikke være behov for å oppdatere klient- eller tjenerkoden. Mellomliggende tjenere kan forbedre systemets skalerbarhet ved å aktivere lastbalansering og ved å tilby delte mellomlagre. Sikkerhet kan også legges til som et lag på toppen av vevtjenestene, og skiller forretningslogikk fra sikkerhetslogikk.^[8] De å legge til sikkerhet som et eget lag håndhever sikkerhetspolicyer. Til slutt kan mellomliggende tjenere kalle flere andre tjenere for å generere et svar til klienten.

Kode på forespørsel (valgfritt)

Tjenere kan midlertidig utvide eller tilpasse funksjonaliteten til en klient ved å overføre kjørbar kode. Dette kan for eksempel være kompilerte komponenter som Java applets eller klient-side skript som JavaScript.

Enhetlig grensesnitt

Begrensningen om et uniformt (eller ensartet) grensesnitt er grunnleggende for utformingen av et RESTful system.^[1] Dette kravet forenkler og dekobler arkitekturen, hvilket gjør at hver del kan utvikle seg selvstendig. De fire begrensningene for det ensartede grensesnittet er:

Ressursidentifikasjon i forespørsler: Individuelle ressurser identifiseres i forespørsler, for eksempel ved å bruke URI-er i RESTful-vevtjenester. Ressursene i seg selv er konseptuelt skilt fra representasjonene som returneres til klienten. For eksempel kan tjeneren sende data fra databasen som HTML, XML eller JSON, men ingen av dem behøver å være tjenerens interne representasjon.
Ressursmanipulering gjennom representasjoner: Når en klient har en representasjon av en ressurs, inkludert enhver medfølgende metadata, har den har nok informasjon til å endre eller slette ressursens tilstand.
Selvbeskrivende meldinger: Hver melding inneholder nok informasjon til å beskrive hvordan meldingen skal behandles. Dette kan for eksempel være hvilken parser som man skal kalle for en gitt mediatype.^[1]
Hypermedia som motor for applikasjonstilstanden (hypermedia as the engine of application state, HATEOAS): For en REST-klient betyr dette at når en har besøkt en initiell URI i en REST-applikasjon så bør klienten være i stand til å gjøre seg nytte av alle tilgjengelige ressurser den trenger. Dette kan sammenlignes med en menneskelig nettbruker som besøker en hjemmeside, og da har mulighet til å navigere seg videre på siden. Etterhvert som innsynet eller adkomsten fortsetter vil tjeneren respondere med tekst som inkluderer hyperlenker til andre ressurser som for tiden er tilgjengelige. Det er ikke nødvendig for klienten å være hardkodet med informasjon om strukturen eller dynamikken i programmet.^[9]

Klassifiseringsmodeller

Flere modeller har blitt utviklet for å klassifisere REST API-er i henhold til i hvilken grad de overholder de ulike prinsipper for REST-design. Et eksempel på en slik klassifiseringsmodell er Richardson maturity model.^[10]

Bruk i vevtjenester

Vevtjenester sine programmeringsgrensesnitt (API-er) som følger REST-stilen kalles for såkalte RESTful API-er.^[11] HTTP-baserte RESTful API-er er definerte med følgende aspekter:^[12]

Grunn-URI, som for eksempel http://api.eksempel.no/;
Standard HTTP-metoder (for eksempel GET, POST, PUT, DELETE);
En mediatype som definerer dataelementer for tilstandsovergang (for eksempel Atom, microformats, application/vnd.collection+json^[12]^:91–99 og så videre). Den gjeldende representasjonen forteller klienten hvordan man komponerer forespørsler om overganger til alle de neste tilgjengelige programtilstandene. Dette kan være så enkelt som en URI eller så komplisert som en Java-applet.^[13]

Semantikk av HTTP-metoder

Tabellen nedenfor viser hvordan HTTP-metoder er ment å brukes i HTTP-API-er, inkludert RESTful.

Semantikk av HTTP-metoder
HTTP-metode	Beskrivelse
GET^[2]^§4.3.1	Få en representasjon av målressursens tilstand.
POST^[2]^§4.3.3	La målressursen behandle representasjonen som er vedlagt i forespørselen.
PUT^[2]^§4.3.4	Opprett eller erstatt tilstanden til målressursen med tilstanden som er definert av representasjonen i forespørselen.
DELETE^[2]^§4.3.5	Slett målressursens tilstand.

GET-metoden er trygg, hvilket betyr at bruk av den på en ressurs ikke resulterer i en tilstandsendring av ressursen (skrivebeskyttet semantikk).^[2]^§4.2.1 Metodene GET, PUT og DELETE er idempotente, hvilket betyr at bruk av dem flere ganger på en ressurs resulterer i samme tilstandsendring av ressursen som å bruke dem en gang, selv om svaret kan variere.^[2]^§4.2.2 Metodene GET og POST er mulige å mellomlagre (cacheable) hvilket betyr at svar på dem tillates å bli lagret for fremtidig gjenbruk.^[2]^§4.2.3

Diskusjon

I motsetning til vevtjenester som følger SOAP-utformingen er det ingen "offisiell" standard for RESTful web-API-er. Dette skyldes at REST er en arkitekonisk stil, mens SOAP er en protokoll. REST er ikke en standard i seg selv, men RESTful-implementeringer benytter seg av standarder, som for eksempel HTTP, URI, JSON og XML. Mange utviklere beskriver API-ene sine som RESTful, selv om de ikke oppfyller alle de arkitektoniske begrensningene som er beskrevet ovenfor (spesielt begrensningen om ett ensartet grensesnitt).^[13]

Se også

Tjenesteorientert arkitektur
SOAP
gRPC
GraphQL, et språk brukt til spørring og manipulering av programmeringsgrensesnitt
OpenAPI Specification

Referanser

^ ^a ^b ^c ^d ^e ^f (Ph.D.). «This chapter introduced the Representational State Transfer (REST) architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, the generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.» Manglende eller tom |tittel= (hjelp)
^ ^a ^b ^c ^d ^e ^f ^g ^h Fielding, Roy. «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4». Internet Engineering Task Force (IETF). Besøkt 14. februar 2018.
^ Couldry, Nick (2012). Media, Society, World: Social Theory and Digital Media Practice. London: Polity Press. s. 2. ISBN 9780745639208.
^ (Ph.D.). Manglende eller tom |tittel= (hjelp)
^ ^a ^b Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). «5.1». SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST. Upper Saddle River, New Jersey: Prentice Hall. ISBN 978-0-13-701251-0.
^ ^a ^b (Ph.D.). Manglende eller tom |tittel= (hjelp)
^ Richardson, Leonard; Ruby, Sam (2007). RESTful Web Services. Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.
^ Lange, Kenneth (2016). The Little Book on REST Services. Copenhagen. s. 19. Besøkt 18. august 2019.
^ «REST HATEOAS». RESTfulAPI.net.
^ Ivan Salvadori, Frank Siqueira (juni 2015). «A Maturity Model for Semantic RESTful Web APIs». Conference: Web Services (ICWS), 2015 IEEE International Conference OnAt: New York - USA – via Researchgate.
^ «What is REST API». Besøkt 29. september 2016.
^ ^a ^b RESTful Web APIs
^ ^a ^b Roy T. Fielding. «REST APIs must be hypertext driven». roy.gbiv.com. Besøkt 6. juli 2016.

[Fielding-Ch5-1] ^ ^a ^b ^c ^d ^e ^f (Ph.D.). «This chapter introduced the Representational State Transfer (REST) architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, the generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.» Manglende eller tom |tittel= (hjelp)

[rfc_7231-2] ^ ^a ^b ^c ^d ^e ^f ^g ^h Fielding, Roy. «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4». Internet Engineering Task Force (IETF). Besøkt 14. februar 2018.

[3] Couldry, Nick (2012). Media, Society, World: Social Theory and Digital Media Practice. London: Polity Press. s. 2. ISBN 9780745639208.

[4] (Ph.D.). Manglende eller tom |tittel= (hjelp)

[SOA_with_REST-5] Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). «5.1». SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST. Upper Saddle River, New Jersey: Prentice Hall. ISBN 978-0-13-701251-0.

[Fielding-Ch2-6] (Ph.D.). Manglende eller tom |tittel= (hjelp)

[Richardson_2007-7] Richardson, Leonard; Ruby, Sam (2007). RESTful Web Services. Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.

[8] Lange, Kenneth (2016). The Little Book on REST Services. Copenhagen. s. 19. Besøkt 18. august 2019.

[RESTfulAPI.net-9] «REST HATEOAS». RESTfulAPI.net.

[10] Ivan Salvadori, Frank Siqueira (juni 2015). «A Maturity Model for Semantic RESTful Web APIs». Conference: Web Services (ICWS), 2015 IEEE International Conference OnAt: New York - USA – via Researchgate.

[11] «What is REST API». Besøkt 29. september 2016.

[Richardson_2013-12] RESTful Web APIs

[must-be-hypertext-driven-13] Roy T. Fielding. «REST APIs must be hypertext driven». roy.gbiv.com. Besøkt 6. juli 2016.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]