Hei! I dag skal vi lære om et tema som er veldig interessant og, viktigst av alt, etterspurt på arbeidsmarkedet: REST. Vi deler vår oversikt over REST i tre deler:
I den første delen skal vi dekke historien til REST og beskrive prinsippene som REST bygger på.
I den andre vil vi vurdere hvordan kommunikasjon mellom en klient og server skjer via HTTP-protokollen.
I den tredje skal vi skrive en liten RESTful-applikasjon som vi skal teste ved hjelp av et program som heter «Postman».
Artikkelen er ment for lesere som er kjent med følgende begreper:
HTTP
URL og URI
JSON og (i mindre grad) XML
Avhengighetsinjeksjon
Del 1. Hva er REST?
REST, som så mye i IT-verdenen, er et akronym. Det er avledet fra "Representational State Transfer" . Dette er en arkitektonisk stil for interaksjon mellom komponenter i et distribuert system i et datanettverk. Enkelt sagt, REST bestemmer stilen for interaksjon (utveksling av data) mellom forskjellige komponenter i systemet, som hver kan være fysisk plassert på forskjellige steder. Denne arkitektoniske stilen er et konsekvent sett med begrensninger som følges når man designer et distribuert system. Disse begrensningene kalles noen ganger de veiledende prinsippene for REST. Det er ikke mange, bare 6. Vi skal snakke om dem litt senere.
Applikasjoner bygget med REST-prinsipper i tankene, dvs. de som ikke bryter med REST-begrensningene, kalles "RESTful".
Historien om REST
Begrepet REST ble introdusert av Roy Fielding, en av skaperne av HTTP-protokollen, i sin Ph.D. avhandling med tittelen "Architectural Styles and the Design of Network-based Software Architectures" i 2000. Selv om begrepet REST fortsatt kan kalles ungt, ligger konseptet det representerer i selve kjernen av World Wide Web. Vi skal ikke dykke dypt inn i begrepets historie. Hvis du ønsker å dykke ned i primærkildene, ta en titt på Fieldings avhandling .
REST-begrensninger og prinsipper
Som nevnt ovenfor, definerer REST hvordan komponentene i et distribuert system skal samhandle med hverandre. Generelt skjer dette gjennom en forespørsel-svar-prosess. Komponenten som sender forespørselen kalles klienten , og komponenten som behandler forespørselen og sender et svar til klienten kalles serveren. Forespørsler og svar sendes oftest via HTTP-protokollen. HTTP står for HyperText Transfer Protocol. Vanligvis er en server en nettapplikasjon. Klienten kan være nesten hva som helst. For eksempel en mobilapp som ber om data fra en server. Eller en nettleser som sender forespørsler fra en nettside til en server for å laste ned data. Applikasjon A kan be om data fra applikasjon B. I dette tilfellet er A en klient med hensyn til B, og B er en server i forhold til A. Samtidig kan A behandle forespørsler fra B, C, D osv. I dette tilfellet er applikasjon A både en server og en klient. Alt avhenger av konteksten. En ting er sikkert: komponenten som sender forespørselen er klienten. Komponenten som mottar, behandler og svarer på en forespørsel er serveren. Derimot, ikke alle systemer hvis komponenter kommuniserer gjennom en forespørsel-svar-prosess er et RESTful-system. For at et system skal anses som RESTfult, må det overholde de seks REST-begrensningene:
1. Klient-server-arkitektur
Denne begrensningen handler om separasjon av bekymringer. Det er nødvendig å skille kravene til klientgrensesnittet fra kravene til serveren som lagrer dataene. Denne begrensningen gjør klientkoden mer portabel til andre plattformer, og å forenkle serversiden forbedrer systemets skalerbarhet. Ved å skille mellom "klienten" og "serveren" kan de utvikles uavhengig av hverandre.
2. Statsløs
En RESTful arkitektur krever at følgende betingelser er oppfylt. I perioden mellom forespørsler skal ikke serveren lagre informasjon om klientens tilstand og omvendt. Alle forespørsler fra klienten må være sammensatt på en måte som gir serveren all nødvendig informasjon for å fullføre forespørselen. Dermed kan både serveren og klienten "forstå" enhver mottatt melding, uten å stole på tidligere meldinger.
3. Bufferbar
Klienter kan hurtigbufre serversvar. Disse må i sin tur eksplisitt eller implisitt angis som bufret eller ikke-bufret, slik at klienter ikke mottar utdaterte eller uriktige data som svar på påfølgende forespørsler. Riktig hurtigbufring bidrar til å helt eller delvis eliminere enkelte klient-server-interaksjoner, og øker systemytelsen og skalerbarheten ytterligere.
4. Ensartet grensesnitt
De grunnleggende kravene til en RESTful arkitektur inkluderer et enhetlig, enhetlig grensesnitt. Klienten må alltid forstå formatet og adressene den må bruke når den sender en forespørsel, og serveren må på sin side også forstå formatet den skal bruke når den svarer på klientforespørsler. Denne konsistente klient-server-interaksjonen som beskriver hva, hvor, i hvilken form og hvordan du sender data, er et enhetlig grensesnitt.
5. Lag
Med lag mener vi den hierarkiske strukturen til nettverket. Noen ganger kan en klient kommunisere direkte med serveren, og noen ganger kommuniserer den bare med en mellomnode. Bruken av mellomservere kan øke skalerbarheten takket være lastbalansering og distribuert caching. La oss gi et eksempel. Se for deg en mobilapp som er populær over hele verden. En integrert del av appen innebærer å laste inn bilder. Brukerne teller i millioner, så en enkelt server kan ikke håndtere en så stor belastning. Å separere systemet i lag vil løse dette problemet. Hvis klienten ber om et bilde fra en mellomnode, så ber den mellomliggende noden om bildet fra serveren som er minst lastet for øyeblikket og returnerer bildet til klienten. Hvis caching brukes riktig på hvert nivå i hierarkiet,
6. Kode på forespørsel (valgfritt)
Denne begrensningen innebærer at klienten kan utvide sin funksjonalitet ved å laste ned kode fra serveren i form av appleter eller skript.
Fordeler med en RESTful arkitektur
Applikasjoner som overholder alle de nevnte begrensningene har følgende fordeler: pålitelighet (ikke nødvendig å lagre klientens tilstand, som kan gå tapt)
Vi deler vår oversikt over REST i tre deler:
