REST (Representational State Transfer) är en arkitekturstil (architectural style) för nätverksapplikationer, definierad av Roy Fielding. Det är inte ett protokoll eller en standard — det är en uppsättning constraints som, när de följs, gör ett API skalbart, cachebart och lätt att utveckla. Ett "RESTful" API modellerar allt som resurser (resources) (users, orders, products) identifierade av URI:er, och manipulerar 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:n /users/42 namnger resursen; GET är handlingen; JSON är representationen. Den kombinationen — substantiv i path:en, verb som HTTP-metoder — är hjärtat i REST.
REST är den dominerande stilen för web-API:er, så intervjuare använder denna fråga för att kontrollera att du förstår varför det fungerar, inte bara att du kan stava till det. De två constraints som spelar störst roll i praktiken är statelessness (varje request är självständig, så du kan sätta hur många servrar som helst bakom en load balancer och skala horisontellt utan sticky sessions) och uniform interface (förutsägbara, resursorienterade URL:er plus standard-HTTP-metoder och status codes, vilket betyder att clients inte behöver anpassad logik per endpoint). Ett starkt svar kopplar constraints till konkreta fördelar — statelessness möjliggör skalning, cachebarhet minskar last, det layered system låter dig infoga CDN:er och gateways — och noterar att de flesta "REST"-API:er är pragmatiska snarare än fullt RESTful (få implementerar HATEOAS). Att förstå dessa constraints är grunden för varje annat REST-designbeslut, från att välja status codes till versioning.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera