REST står For Representational State Transfer, et begrep skapt Av Roy Fielding i 2000. Det er en arkitektur stil for å designe løst koblede applikasjoner OVER HTTP, som ofte brukes i utviklingen av webtjenester. REST håndhever ikke noen regel om hvordan den skal implementeres på lavere nivå, det legger bare retningslinjer for høyt nivå og lar deg tenke på din egen implementering.
i min siste ansettelse designet Jeg RESTful Apier for et stort teleselskap i to gode år. I dette innlegget vil jeg dele mine tanker bortsett fra standard designpraksis. Du er kanskje ikke enig med meg på noen punkter, og det er helt OK. Jeg vil gjerne diskutere noe fra deg med et åpent sinn.
La oss starte med standard designspesifikke ting for å fjerne hva’ Roy Fielding ‘ vil at Vi skal bygge. Da vil vi diskutere mine tanker, som vil være mer mot finere poeng mens du utformer Dine Avslappende Apier.
Arkitektoniske Begrensninger
REST definerer 6 arkitektoniske begrensninger som gjør enhver webtjeneste-en Ekte RESTful API.
- Enhetlig grensesnitt
- Klient-server
- Statsløs
- Cacheable
- Lagdelt system
- Kode på forespørsel (valgfritt)
Uniform interface
som begrensningsnavnet selv gjelder, MÅ Du bestemme Api-grensesnitt for ressurser inne i systemet som er utsatt FOR API-forbrukere og følger religiøst. En ressurs i systemet skal bare ha en logisk URI, og det skal gi en måte å hente relaterte eller ekstra data på. Det er alltid bedre å synonymisere en ressurs med en nettside.
Enhver enkelt ressurs bør ikke være for stor og inneholde hver og alt i sin representasjon. Når det er relevant, bør en ressurs inneholde lenker (HATEOAS) som peker på relative Urier for å hente relatert informasjon.
ressursrepresentasjonene på tvers av systemet bør også følge spesifikke retningslinjer som navnekonvensjoner, koblingsformater eller dataformat (XML eller/og JSON).
alle ressurser bør være tilgjengelige gjennom en felles tilnærming, FOR EKSEMPEL HTTP GET, og tilsvarende modifisert ved hjelp av en konsekvent tilnærming.
Client–server
denne begrensningen betyr i hovedsak at klientprogram og serverprogram MÅ kunne utvikle seg separat uten avhengighet av hverandre. En klient bør kun vite ressurs Urier, og det er alt. I dag er dette standard praksis i webutvikling, så det er ikke nødvendig med noe fancy fra din side. Hold det enkelt.
Statsløs
Roy fielding fikk inspirasjon FRA HTTP, så det reflekterer i denne begrensningen. Gjør alle klient-server-interaksjoner statsløse. Serveren vil ikke lagre noe om den nyeste HTTP-forespørselen klienten har gjort. Det vil behandle hver forespørsel som ny. Ingen sesjon, ingen historie.
hvis klientprogrammet må være et stateful program for sluttbrukeren, der brukeren logger inn en gang og gjør andre autoriserte operasjoner etter det, bør hver forespørsel fra klienten inneholde all nødvendig informasjon for å betjene forespørselen-inkludert autentiserings-og autorisasjonsdetaljer.
Cacheable
i dagens verden er caching av data og svar av største betydning hvor de er aktuelle/mulige. Websiden du leser her er også en bufret versjon AV HTML-siden. Caching gir ytelsesforbedring for klientsiden og bedre mulighet for skalerbarhet for en server fordi belastningen har redusert.
I REST skal caching brukes på ressurser når det er aktuelt, og da må disse ressursene erklære seg cacheable. Caching kan implementeres på serveren eller klientsiden.
Lagdelt system
REST lar DEG bruke en lagdelt systemarkitektur der Du distribuerer Apiene på server A, og lagrer data På server B og godkjenner forespørsler i Server C, for eksempel. En klient kan vanligvis ikke fortelle om den er koblet direkte til sluttserveren eller en mellommann underveis.
Kode på forespørsel (valgfritt)
vel, denne begrensningen er valgfri. Mesteparten av tiden vil du sende statiske representasjoner av ressurser i FORM AV XML eller JSON. Men når du trenger det, er du fri til return executable code for å støtte en del av søknaden din, f.eks. Det er tillatt.
Legg Merke til at alle de ovennevnte begrensningene er nært knyttet TIL WWW (web). Ved Hjelp Av RESTful Apier kan du gjøre det samme med webtjenestene dine hva du gjør med nettsider.