REST (Representational State Transfer) er en arkitekturstil for nettverksapplikasjoner, definert av Roy Fielding. Det er ikke en protokoll eller en standard — det er et sett med begrensninger (constraints) som, når de følges, gjør et API skalerbart, cachebart og lett å videreutvikle. Et "RESTful" API modellerer alt som ressurser (users, orders, products) identifisert med URI-er, og manipulerer dem med standard HTTP-metoder.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI-en /users/42 navngir ressursen; GET er handlingen; JSON er representasjonen. Den kombinasjonen — substantiv i pathen, verb som HTTP-metoder — er kjernen i REST.
REST er den dominerende stilen for web-API-er, så intervjuere bruker dette spørsmålet til å sjekke at du forstår hvorfor det virker, ikke bare at du kan stave det. De to begrensningene som betyr mest i praksis er statelessness (hver request er selvstendig, så du kan sette et hvilket som helst antall servere bak en load balancer og skalere horisontalt uten sticky sessions) og uniform interface (forutsigbare, ressursorienterte URL-er pluss standard HTTP-metoder og statuskoder, som betyr at klienter ikke trenger egen logikk per endepunkt). Et sterkt svar knytter begrensningene til konkrete fordeler — statelessness muliggjør skalering, cachebarhet reduserer last, det lagdelte systemet lar deg sette inn CDN-er og gatewayer — og bemerker at de fleste "REST"-API-er er pragmatiske snarere enn fullt RESTful (få implementerer HATEOAS). Å forstå disse begrensningene er grunnlaget for hver eneste andre REST-designbeslutning, fra valg av statuskoder til versjonering.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner