REST (Representational State Transfer) is een architectuurstijl voor netwerkapplicaties, gedefinieerd door Roy Fielding. Het is geen protocol of standaard — het is een verzameling constraints die, wanneer gevolgd, een API schaalbaar, cachebaar en makkelijk te laten evolueren maken. Een "RESTful" API modelleert alles als resources (users, orders, products) geïdentificeerd door URI's, en manipuleert ze met standaard HTTP-methoden.
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]" }
De URI /users/42 benoemt de resource; GET is de actie; JSON is de representatie. Die combinatie — zelfstandige naamwoorden in het pad, werkwoorden als HTTP-methoden — is het hart van REST.
REST is de dominante stijl voor web-API's, dus interviewers gebruiken deze vraag om te checken of je begrijpt waarom het werkt, niet alleen dat je het kunt opnoemen. De twee constraints die in de praktijk het meest tellen zijn statelessness (elke request is zelfvoorzienend, dus je kunt een willekeurig aantal servers achter een load balancer zetten en horizontaal schalen zonder sticky sessions) en de uniform interface (voorspelbare, resource-georiënteerde URL's plus standaard HTTP-methoden en statuscodes, wat betekent dat clients geen custom logica per endpoint nodig hebben). Een sterk antwoord verbindt de constraints met concrete voordelen — statelessness maakt schalen mogelijk, cachebaarheid verlaagt de belasting, het layered system laat je CDN's en gateways invoegen — en merkt op dat de meeste "REST"-API's pragmatisch zijn in plaats van volledig RESTful (weinig implementeren HATEOAS). Deze constraints begrijpen is de basis voor elke andere REST-ontwerpbeslissing, van het kiezen van statuscodes tot versioning.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren