REST API sollicitatievragen en antwoorden (2026): Methoden, Statuscodes en Ontwerp

REST API-vragen testen of je een interface kunt ontwerpen die anderen zonder verrassingen kunnen gebruiken. Hieronder staan 20 vragen met antwoorden, van de basis tot de ontwerpdetails die in backend- en full-stackinterviews aan bod komen. Voor de regels rond HTTP-methoden hebben we de definities uit RFC 9110 gevolgd.

Basis

1. Wat is REST?

REST is een architectuurstijl voor genetwerkte systemen, gebouwd rond resources die door URL's worden geïdentificeerd, gemanipuleerd met een kleine set standaardbewerkingen en beschreven door representaties zoals JSON. Een REST API is stateless: elk verzoek bevat wat de server nodig heeft om het te verwerken, zodat elke server elk verzoek kan afhandelen.

2. Wat maakt een API in de praktijk "RESTful"?

• Zelfstandige naamwoorden voor resources in URL's, zoals /orders/42, niet werkwoorden zoals /getOrder
• Standaard HTTP-methoden voor acties
• Betekenisvolle statuscodes
• Stateless verzoeken
• Consistente representaties en foutstructuren

Zeg in interviews dat weinig echte API's aan elke REST-beperking voldoen, en dat je streeft naar voorspelbaar gedrag.

3. Waarvoor worden de belangrijkste HTTP-methoden gebruikt?

"Veilig" betekent dat het verzoek de serverstatus niet wijzigt. "Idempotent" betekent dat het meerdere keren versturen hetzelfde effect heeft als het één keer versturen.

4. Wat betekent idempotent, en waarom is dat belangrijk?

Als een verzoek wordt herhaald, is de eindtoestand hetzelfde als na één verzoek. Het is belangrijk omdat netwerken falen. Als een client een timeout krijgt bij een PUT, kan die het opnieuw proberen zonder bang te zijn. Een POST die een order aanmaakt, zou er twee kunnen aanmaken, dus API's accepteren vaak een idempotency key: de client stuurt een unieke sleutel, en de server geeft het opgeslagen resultaat terug als hij de sleutel opnieuw ziet.

5. PUT of PATCH?

PUT vervangt de hele resource door de body die je stuurt, en velden die je weglaat worden gewist of teruggezet. PATCH wijzigt alleen de velden die je stuurt. Gebruik PATCH voor kleine updates en PUT wanneer de client de volledige representatie heeft.

Statuscodes en fouten

6. Welke statuscodes gebruik je, en wanneer?

Een veelvoorkomende vervolgvraag is het verschil tussen 401 en 403. 401 betekent "ik weet niet wie je bent", en 403 betekent "ik weet wie je bent, en je mag dit niet doen".

7. Hoe moet een API fouten teruggeven?

Gebruik de juiste statuscode en een consistente body. Een goede foutbody heeft een stabiele, machineleesbare code, een menselijk leesbare melding en, bij validatiefouten, welke velden zijn mislukt. Lek geen stacktraces of interne details naar clients.

8. Hoe ga je om met validatie?

Valideer op de server, zelfs als de client ook valideert. Geef alle problemen in één keer terug wanneer dat kan, zodat de gebruiker ze niet één voor één hoeft op te lossen, en gebruik 400 of 422 consistent.

Ontwerp

9. Hoe ontwerp je URL's voor relaties?

Nest wanneer het kind alleen betekenis heeft onder de ouder, zoals /users/7/orders. Houd nesting ondiep. Voorbij één of twee niveaus exposeer je het kind direct, zoals /orders/42, en filter je met queryparameters, zoals /orders?userId=7.

10. Hoe pagineer je een lijst?

Cursor-paginering is het gebruikelijke antwoord voor grote of snel veranderende data. Retourneer de volgende cursor en een hint of er meer resultaten zijn.

11. Hoe filter en sorteer je?

Gebruik queryparameters, zoals ?status=open&sort=-created_at. Whitelist de velden die je toestaat, om te voorkomen dat je niet-geïndexeerde of gevoelige kolommen blootstelt en om queries snel te houden.

12. Hoe versioneer je een API?

Wat je ook kiest, vermijd breaking changes binnen een versie. Velden toevoegen is meestal veilig, en velden verwijderen of hernoemen is dat niet.

13. Wat is HATEOAS?

Responses bevatten links naar gerelateerde acties, zodat een client kan ontdekken wat hij vervolgens kan doen in plaats van URL's hard te coderen. Het maakt deel uit van de REST-definitie, maar weinig API's implementeren het volledig. Zeg dat je het kent en dat de meeste teams documentatie en een OpenAPI-beschrijving gebruiken in plaats daarvan.

Beveiliging en prestaties

14. Hoe authenticeer je een API?

Veelvoorkomende keuzes zijn API-sleutels voor eenvoudig server-naar-server-gebruik, bearer-tokens zoals JSON Web Tokens, en OAuth 2.0 wanneer een gebruiker een app toegang geeft tot zijn data. Gebruik altijd HTTPS. Houd secrets uit URL's, want URL's belanden in logs.

15. Wat is het verschil tussen authenticatie en autorisatie?

Authenticatie is bewijzen wie je bent. Autorisatie is bepalen wat je mag doen. Ze falen verschillend: een ontbrekend of ongeldig token is 401, en een geldig token zonder toestemming is 403.

16. Hoe bescherm je een API tegen misbruik?

Rate limiting per sleutel of per IP, limieten op requestgrootte, inputvalidatie, timeouts en monitoring op ongebruikelijk verkeer. Retourneer 429 met een Retry-After-header zodat clients weten wanneer ze het opnieuw kunnen proberen.

17. Hoe werkt HTTP-caching voor API's?

Responses kunnen Cache-Control-headers bevatten die aangeven hoe lang een response hergebruikt mag worden. Een ETag identificeert een versie van de response. De client stuurt die terug in If-None-Match, en de server antwoordt 304 Not Modified zonder body als er niets is veranderd. Het bespaart bandbreedte en belasting.

18. Wat is CORS?

Browsers blokkeren dat een webpagina responses van een andere origin leest, tenzij de server het toestaat. De server stuurt headers zoals Access-Control-Allow-Origin om te zeggen welke origins zijn responses mogen lezen. Het wordt afgedwongen door de browser, niet door de server, dus het beschermt een API niet tegen niet-browser-clients.

Praktisch

19. REST of GraphQL of gRPC?

Het beste antwoord noemt een situatie, niet een winnaar.

20. Hoe documenteer en test je een API?

Beschrijf het met een OpenAPI-specificatie, die documentatie en clientcode kan genereren. Test op drie niveaus: unit tests voor de logica, integratietests tegen een echte database, en contracttests om breaking changes op te vangen. Probeer ook de faalgevallen, zoals ongeldige input en verlopen tokens.

Hoe je je voorbereidt

1. Wees in staat om een kleine API op een whiteboard te ontwerpen, zoals een to-do-lijst of een ordersysteem, met URL's, methoden, statuscodes en één errorresponse.
2. Ken idempotentie en paginering door en door. Die komen het meest aan bod.
3. Bereid een verhaal voor over een API die je hebt gebouwd of gebruikt, en één fout die je de volgende keer zou vermijden.

Voor gerelateerde oefening, zie onze gidsen over Spring Boot interviewvragen, Node.js interviewvragen, system design interviewvragen, en computernetwerk interviewvragen.

Oefen hardop en in je eigen woorden. Een transcript achteraf laat zien waar je afdwaalde of het punt miste. Volg de regels van de werkgever over AI-tools in elk live interview of assessment.