REST arkitektoniske begrænsninger

REST står for Representational State Transfer, et udtryk opfundet af Roy Fielding i 2000. Det er en arkitekturstil til at designe løst koblede applikationer via HTTP, der ofte bruges til udvikling af internettjenester. REST håndhæver ikke nogen regel om, hvordan den skal implementeres på lavere niveau, det sætter bare designretningslinjer på højt niveau og lader dig tænke på din egen implementering.

i min sidste ansættelse designede jeg RESTful API ‘ er til et større teleselskab i to gode år. I dette indlæg vil jeg dele mine tanker bortset fra standard design praksis. Du er måske ikke enig med mig på et par punkter, og det er helt OK. Jeg vil med glæde diskutere alt fra dig med et åbent sind.

lad os starte med standard design specifikke ting for at rydde, hvad ‘Roy Fielding’ vil have os til at bygge. Så vil vi diskutere mine tanker, som vil være mere mod finere punkter, mens du designer dine afslappende API ‘ er.

arkitektoniske begrænsninger

REST definerer 6 arkitektoniske begrænsninger, der gør enhver internettjeneste – en ægte afslappende API.

1. ensartet grænseflade
2. klient-server
3. statsløs
4. Cacheable
5. lagdelt system
6. kode efter behov (valgfrit)

Uniform interface

da selve begrænsningsnavnet gælder, skal du beslutte API ‘ er interface for ressourcer inde i systemet, der udsættes for API-forbrugere og følger religiøst. En ressource i systemet skal kun have en logisk URI, og det skal give en måde at hente relaterede eller yderligere data på. Det er altid bedre at synonymisere en ressource med en hjemmeside.

enhver enkelt ressource bør ikke være for stor og indeholde alt i sin repræsentation. Når det er relevant, skal en ressource indeholde links (HATEOAS), der peger på relative Uri ‘ er for at hente relateret information.

ressourcerepræsentationerne på tværs af systemet skal også følge specifikke retningslinjer som navngivningskonventioner, linkformater eller dataformat.

alle ressourcer skal være tilgængelige via en fælles tilgang som HTTP GET og tilsvarende ændret ved hjælp af en ensartet tilgang.

Client–server

denne begrænsning betyder i det væsentlige, at klientapplikation og serverapplikation skal kunne udvikle sig separat uden nogen afhængighed af hinanden. En klient bør kun kende ressource Uri ‘ er, og det er alt. I dag er dette standard praksis inden for internetudvikling, så der kræves intet fancy fra din side. Hold det simpelt.

statsløs

Roy fielding fik inspiration fra HTTP, så det afspejler sig i denne begrænsning. Gør alle klient-server interaktioner statsløse. Serveren gemmer ikke noget om den seneste HTTP-anmodning, som klienten har foretaget. Det vil behandle enhver anmodning som ny. Ingen session, ingen historie.

hvis klientapplikationen skal være en stateful applikation for slutbrugeren, hvor brugeren logger ind en gang og udfører andre autoriserede operationer efter det, skal hver anmodning fra klienten indeholde alle de oplysninger, der er nødvendige for at servicere anmodningen-inklusive godkendelsesoplysninger og autorisationsoplysninger.

Cacheable

i dagens verden er caching af data og svar af største betydning, hvor de er anvendelige/mulige. Den hjemmeside, du læser her, er også en cachelagret version af HTML-siden. Caching giver præstationsforbedring for klientsiden og bedre mulighed for skalerbarhed for en server, fordi belastningen er reduceret.

i REST skal caching anvendes på ressourcer, når det er relevant, og derefter skal disse ressourcer erklære sig cacheable. Caching kan implementeres på serveren eller klientsiden.

Layered system

REST giver dig mulighed for at bruge en lagdelt systemarkitektur, hvor du implementerer API ‘ erne på server A, og gemme data på server B og godkende anmodninger i Server C, for eksempel. En klient kan normalt ikke fortælle, om den er tilsluttet direkte til slutserveren eller en mellemmand undervejs.

kode efter behov (valgfrit)

nå, denne begrænsning er valgfri. Det meste af tiden vil du sende de statiske repræsentationer af ressourcer i form af JSON. Men når du har brug for det, er du fri til return executable code for at understøtte en del af din ansøgning, f.eks. Det er tilladt.

Bemærk, at alle ovenstående begrænsninger er mest nært beslægtede med (internettet). Ved hjælp af RESTful API ‘ er kan du gøre det samme med dine internettjenester, hvad du gør med hjemmesider.