HTTP-methods verklaren je intentie op een resource; status codes zijn het gecodeerde antwoord van de server. Twee eigenschappen zijn belangrijk voor methods: safe (alleen-lezen, geen side effects) en idempotent (herhalen levert hetzelfde resultaat — belangrijk voor veilige retries).
| Method | Doel | Safe | Idempotent |
|---|
| GET | Een resource lezen | Ja | Ja |
| POST | Aanmaken / actie triggeren | Nee | Nee |
| PUT | Een resource vervangen | Nee | Ja |
| PATCH | Gedeeltelijk bijwerken | Nee | Nee* |
| DELETE | Een resource verwijderen | Nee | Ja |
| HEAD | Als GET, alleen headers | Ja | Ja |
Het idempotency-onderscheid is praktisch: omdat PUT en DELETE idempotent zijn, kan een client ze veilig opnieuw proberen na een timeout; een non-idempotente POST opnieuw proberen riskeert een duplicaat te maken (een klassieke double-charge-bug).
Status codes worden gegroepeerd op hun eerste cijfer:
1xx Informational request received, continuing (100 Continue, 101 Switching)
2xx Success it worked (200 OK, 201 Created, 204 No Content)
3xx Redirection go elsewhere (301 Moved, 304 Not Modified)
4xx Client error YOUR request is wrong (400, 401, 403, 404, 429)
5xx Server error the SERVER failed (500, 502, 503, 504)
De belangrijkste scheidslijn is de 4xx vs 5xx-splitsing: 4xx betekent dat de client iets verkeerds stuurde (slechte input, niet geauthenticeerd, niet gevonden) — ongewijzigd opnieuw proberen helpt niet; 5xx betekent dat de server faalde — opnieuw proberen (met backoff) kan slagen. Ken de alledaagse uit je hoofd: 401 (niet geauthenticeerd) vs 403 (geauthenticeerd maar niet toegestaan), 404 (niet gevonden), 429 (rate limited), 500 (generieke server-crash), 502/503/504 (bad gateway / niet beschikbaar / gateway timeout — meestal een upstream- of overbelastingsprobleem).
Deze codes zijn het gedeelde contract tussen elke client en server, dus vloeiendheid hier wordt verwacht van iedereen die API's bouwt of consumeert. Interviewers peilen de onderscheiden die echt begrip onthullen: 401 vs 403, PUT vs PATCH, en vooral idempotency, die direct bepaalt of retries veilig zijn — een kernzorg in gedistribueerde systemen en betaalflows. De juiste status code retourneren maakt je API ook voorspelbaar en correct afgehandeld door caches, proxies en client libraries, dus deze kennis vormt goed API-ontwerp, niet zomaar triviakennis.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren