Hej! I dag vil vi lære om et emne, der er meget interessant og, vigtigst af alt, meget efterspurgt på arbejdsmarkedet: REST. Vi vil opdele vores oversigt over REST i tre dele:
I første del vil vi dække historien om REST og beskrive de principper, som REST er baseret på.
I det andet vil vi overveje, hvordan kommunikationen mellem en klient og server foregår via HTTP-protokollen.
I den tredje vil vi skrive en lille RESTful applikation, som vi tester ved hjælp af et program kaldet "Postmand".
Artiklen er beregnet til læsere, der er bekendt med følgende udtryk:
HTTP
URL og URI
JSON og (i mindre grad) XML
Afhængighedsindsprøjtning
Del 1. Hvad er REST?
REST, som så meget i IT-verdenen, er et akronym. Det er afledt af "Representational State Transfer" . Dette er en arkitektonisk stil til interaktion mellem komponenter i et distribueret system i et computernetværk. Kort sagt bestemmer REST stilen for interaktion (udveksling af data) mellem forskellige komponenter i systemet, som hver især kan være fysisk placeret forskellige steder. Denne arkitektoniske stil er et konsekvent sæt af begrænsninger, der overholdes, når man designer et distribueret system. Disse begrænsninger kaldes nogle gange de vejledende principper for REST. Der er ikke mange, kun 6. Dem vil vi tale om lidt senere.
Applikationer bygget med REST-principper i tankerne, dvs. dem, der ikke overtræder REST-begrænsningerne, kaldes "RESTful".
Historien om REST
Udtrykket REST blev introduceret af Roy Fielding, en af skaberne af HTTP-protokollen, i sin ph.d. afhandling med titlen "Architectural Styles and the Design of Network-based Software Architectures" i 2000. Selvom begrebet REST stadig kan kaldes ungt, ligger det koncept, det repræsenterer, i selve kernen af World Wide Web. Vi vil ikke dykke dybt ned i udtrykkets historie. Hvis du vil dykke ned i de primære kilder, så tag et kig på Fieldings afhandling .
REST begrænsninger og principper
Som nævnt ovenfor definerer REST, hvordan komponenterne i et distribueret system skal interagere med hinanden. Generelt sker dette gennem en anmodning-svar-proces. Den komponent, der sender anmodningen, kaldes klienten , og den komponent, der behandler anmodningen og sender et svar til klienten, kaldes serveren. Forespørgsler og svar sendes oftest via HTTP-protokollen. HTTP står for HyperText Transfer Protocol. Typisk er en server en webapplikation. Klienten kan være næsten alt. For eksempel en mobilapp, der anmoder om data fra en server. Eller en browser, der sender anmodninger fra en webside til en server for at downloade data. Applikation A kan anmode om data fra applikation B. I dette tilfælde er A en klient med hensyn til B, og B er en server i forhold til A. Samtidig kunne A behandle anmodninger fra B, C, D osv. I dette tilfælde er applikation A både en server og en klient. Alt afhænger af konteksten. En ting er sikker: den komponent, der sender anmodningen, er klienten. Den komponent, der modtager, behandler og reagerer på en anmodning, er serveren. Imidlertid, ikke alle systemer, hvis komponenter kommunikerer gennem en anmodning-svar-proces, er et RESTful-system. For at et system kan betragtes som RESTful, skal det overholde de seks REST-begrænsninger:
1. Klient-server-arkitektur
Denne begrænsning handler om adskillelse af bekymringer. Det er nødvendigt at adskille kravene til klientgrænsefladen fra kravene til serveren, der gemmer dataene. Denne begrænsning gør klientkoden mere bærbar til andre platforme, og forenkling af serversiden forbedrer systemets skalerbarhed. Ved at skelne mellem "klienten" og "serveren" kan de udvikles uafhængigt af hinanden.
2. Statsløs
En RESTful arkitektur kræver, at følgende betingelser er opfyldt. I perioden mellem anmodninger må serveren ikke gemme information om klientens tilstand og omvendt. Alle anmodninger fra klienten skal være sammensat på en måde, der giver serveren alle nødvendige oplysninger for at fuldføre anmodningen. Således kan både serveren og klienten "forstå" enhver modtaget besked uden at stole på tidligere beskeder.
3. Cachebar
Klienter kan cache serversvar. Disse skal til gengæld eksplicit eller implicit betegnes som cachelagrede eller ikke-cachelagrede, således at klienter ikke modtager forældede eller forkerte data som svar på efterfølgende anmodninger. Korrekt caching hjælper med helt eller delvist at eliminere nogle klient-server-interaktioner, hvilket yderligere øger systemets ydeevne og skalerbarhed.
4. Ensartet interface
De grundlæggende krav til en RESTful arkitektur omfatter en samlet, ensartet grænseflade. Klienten skal altid forstå det format og de adresser, den skal bruge, når den sender en forespørgsel, og serveren skal til gengæld også forstå det format, den skal bruge, når den svarer på kundens anmodninger. Denne konsekvente klient-server-interaktion, der beskriver hvad, hvor, i hvilken form og hvordan man sender data, er en samlet grænseflade.
5. Lag
Med lag mener vi netværkets hierarkiske struktur. Nogle gange kan en klient kommunikere direkte med serveren, og nogle gange kommunikerer den bare med en mellemnode. Brugen af mellemliggende servere kan øge skalerbarheden takket være belastningsbalancering og distribueret caching. Lad os give et eksempel. Forestil dig en mobilapp, der er populær over hele verden. En integreret del af appen involverer indlæsning af billeder. Dens brugere tæller i millioner, så en enkelt server kan ikke klare så stor en belastning. At adskille systemet i lag vil løse dette problem. Hvis klienten anmoder om et billede fra en mellemknude, anmoder den mellemliggende knude det billede fra serveren, der er mindst indlæst i øjeblikket, og returnerer billedet til klienten. Hvis caching anvendes korrekt på hvert niveau i hierarkiet,
6. Kode efter behov (valgfrit)
Denne begrænsning indebærer, at klienten kan udvide sin funktionalitet ved at downloade kode fra serveren i form af applets eller scripts.
Fordele ved en RESTful arkitektur
Applikationer, der overholder alle de førnævnte begrænsninger, har følgende fordele: pålidelighed (ingen grund til at gemme klientens tilstand, som kan gå tabt)
Vi vil opdele vores oversigt over REST i tre dele:
GO TO FULL VERSION