REST API-sollicitatievragen en -antwoorden (gids 2026)

REST-API’s drijven het merendeel van de integraties op internet. Of je nu solliciteert voor een backend-rol, een fullstack-functie of een job als software engineer, de kans is groot dat je vragen krijgt over REST API-ontwerp, HTTP-methoden en authenticatiepatronen.

In deze gids neem ik je mee door de vragen die recruiters daadwerkelijk stellen. Ik heb ze georganiseerd op moeilijkheidsniveau en roletype, zodat je je kunt richten op wat het belangrijkst is voor de functie waarop je mikt. Elk antwoord bevat praktische voorbeelden en, waar relevant, codefragmenten die je kunt aanpassen.

Eén ding om in gedachten te houden: interviewers testen veel vaker de basis dan geavanceerde onderwerpen. Als je de basis (HTTP-methoden, statuscodes, statelessness) goed beheerst, kun je de meeste REST-API-interviews met vertrouwen aan. De fancy architectuurpatronen komen later.

Basis REST API-sollicitatievragen

Deze vragen testen je fundamentele kennis. Verwacht ze in vrijwel elk interview, ongeacht je senioriteitsniveau.

1. Wat is REST en wat zijn de constraints?

REST staat voor Representational State Transfer. Het is een architecturale stijl voor het ontwerpen van netwerkapplicaties, gedefinieerd door Roy Fielding in zijn proefschrift uit 2000.

REST kent zes constraints:

1. Client-Server: Scheiding van verantwoordelijkheden tussen de gebruikersinterface en gegevensopslag
2. Stateless: Elke aanvraag bevat alle informatie die nodig is om deze af te handelen
3. Cacheable: Responses moeten aangeven of ze te cachen zijn
4. Layered System: Componenten kunnen niet verder kijken dan hun directe laag
5. Uniform Interface: Gestandaardiseerde manier om met resources te werken
6. Code-on-Demand (optioneel): Servers kunnen uitvoerbare code naar clients sturen

2. Wat is het verschil tussen REST en SOAP?

REST is een architecturale stijl; SOAP is een protocol. REST gebruikt doorgaans JSON over HTTP en maakt gebruik van standaard HTTP-methoden. SOAP gebruikt exclusief XML en definieert een eigen berichtindeling met enveloppen en headers.

SOAP is nog steeds zinvol voor bedrijfssystemen die formele contracten (WSDL) of security op berichtniveau (WS-Security) vereisen.

3. Wat zijn HTTP-methoden en wanneer gebruik je welke?

HTTP-methoden definiëren de actie die op een resource moet worden uitgevoerd.

4. Wat is het verschil tussen PUT en POST?

POST maakt een nieuwe resource aan waarbij de server de URI bepaalt. PUT vervangt een resource op een specifieke URI die de client opgeeft.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Als je PUT naar een URI die niet bestaat, kan de server deze aanmaken. Als je PUT naar een bestaande URI, vervang je de volledige resource.

5. Wat is het verschil tussen PUT en PATCH?

PUT vervangt de volledige resource. PATCH past gedeeltelijke wijzigingen toe.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. Wat betekent "stateless" in REST?

Stateless betekent dat elke aanvraag alle informatie moet bevatten die de server nodig heeft om deze te verwerken. De server bewaart geen clientcontext tussen aanvragen.

Dit betekent geen server-side sessies. Als een gebruiker geauthenticeerd is, moet de client bij elke aanvraag inloggegevens (meestal een token) meesturen.

7. Wanneer is een API RESTful?

Een API is echt RESTful wanneer deze aan alle REST-constraints voldoet, inclusief HATEOAS (Hypermedia as the Engine of Application State). In de praktijk zijn de meeste API’s die zichzelf "REST" noemen eigenlijk "REST-achtig" of op niveau 2 van het Richardson Maturity Model. En eerlijk gezegd is dat voor de meeste use-cases prima.

Richardson Maturity Model-niveaus voor REST-API’s. Afbeelding door de auteur.

8. Wat zijn de basis HTTP-statuscodes die je moet kennen?

Je zou minstens deze zeven essentiële statuscodes moeten kennen die het merendeel van de API-scenario’s afdekken:

9. Wat is het verschil tussen een resource en een endpoint?

Een resource is de gegevensentiteit (gebruiker, bestelling, product). Een endpoint is het URL-pad dat toegang biedt tot die resource.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. Wat zijn best practices voor URI-ontwerp?

Gebruik zelfstandige naamwoorden, geen werkwoorden. Houd URI’s lowercase met koppeltekens voor meerwoordnamen. Gebruik meervoud voor collecties.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Vermijd diepe nesting. In plaats van /users/123/posts/456/comments/789, overweeg /comments/789 of /comments?post_id=456.

11. Wat is idempotentie en welke HTTP-methoden zijn idempotent?

Een bewerking is idempotent als deze meerdere keren uitvoeren hetzelfde resultaat oplevert als één keer uitvoeren.

Een PATCH die een waarde zet is idempotent; een PATCH die een teller ophoogt niet.

12. Wat is het verschil tussen veilige en idempotente methoden?

Veilige methoden wijzigen geen resources (GET, HEAD, OPTIONS). Idempotente methoden kunnen meerdere keren worden aangeroepen met hetzelfde effect (GET, PUT, DELETE).

Alle veilige methoden zijn idempotent, maar niet alle idempotente methoden zijn veilig. DELETE is idempotent maar niet veilig omdat het de staat wijzigt.

13. Wanneer gebruik je queryparameters versus padparameters?

Padparameters identificeren een specifieke resource. Queryparameters filteren, sorteren of pagineren collecties.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. Wat is content negotiation?

Content negotiation maakt het mogelijk dat clients verschillende representaties van een resource aanvragen. De client stuurt een Accept-header, en de server antwoordt met het juiste formaat.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. Wat is het doel van de OPTIONS-methode?

OPTIONS geeft de HTTP-methoden terug die een server ondersteunt voor een specifieke URL. Browsers gebruiken dit voor CORS-preflight-aanvragen om te controleren of cross-origin-aanvragen zijn toegestaan.

Intermediaire REST API-sollicitatievragen

Deze vragen testen praktische toepassing en besluitvorming. Verwacht ze voor mediorfuncties.

16. Wat is het verschil tussen 401 en 403?

Dit is het meest verwarde paar statuscodes. Ik heb senior engineers dit in code reviews zien verwisselen.

401 Unauthorized

Betekent niet geauthenticeerd. De server weet niet wie je bent. Je reactie moet de gebruiker vragen om in te loggen.

403 Forbidden

Betekent niet geautoriseerd. De server weet wie je bent, maar je mist toestemming. Opnieuw inloggen helpt niet.

Beslisdiagram authenticatie versus autorisatiefouten. Afbeelding door de auteur.

17. Wat is het verschil tussen 400 en 422?

Hier zijn voorbeelden die het verschil illustreren:

400 Bad Request

Dit duidt op ongeldige syntaxis. De server kan de aanvraag niet parseren (ongeldige JSON-structuur, ontbrekende vereiste headers).

422 Unprocessable Entity

Dit duidt op geldige syntaxis maar semantische fouten. De JSON is geldig, maar de data faalt validatie (ongeldig e-mailformaat, wachtwoord te kort).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. Wanneer gebruik je 409 Conflict?

Gebruik 409 wanneer de aanvraag in conflict is met de huidige staat van de resource:

• Optimistic locking-fouten (ETag mismatch)
• Schendingen van uniciteitsconstraints (dubbele gebruikersnaam)
• Ongeldige toestandovergangen (een al verzonden bestelling annuleren)

19. Hoe implementeer je paginering?

Twee hoofdbenaderingen:

Offset-gebaseerde paginering

Eenvoudig maar prestatieproblemen bij grote datasets.

GET /users?limit=20&offset=40

Cursor-gebaseerde paginering

Schaalt beter en voorkomt "page drift" wanneer data verandert.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Bedrijven als Stripe, GitHub en Slack gebruiken cursor-gebaseerde paginering voor grote datasets.

20. Wat zijn gangbare strategieën voor API-versiebeheer?

Er zijn drie hoofdbenaderingen, elk met verschillende trade-offs:

URI-versiebeheer

Dit is de meest voorkomende. Het is expliciet en eenvoudig te debuggen.

GET /v1/users
GET /v2/users

Header-versiebeheer

Schonere URL’s maar lastiger te testen in browsers.

GET /users
Accept-Version: v2

Queryparameter-versiebeheer

Makkelijk toe te voegen maar vervuilt URL’s.

GET /users?version=2

21. Wat is een ETag en hoe werkt caching?

Een ETag is een versie-identificator voor een resource. De server stuurt deze mee in responses; de client stuurt hem terug in volgende aanvragen om te controleren of de resource is gewijzigd.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. Welke authenticatiemethoden worden gebruikt voor REST-API’s?

De vier meest voorkomende authenticatiemethoden zijn API Keys, Bearer Tokens, OAuth 2.0 en JWT:

23. Wat is JWT en hoe werkt het?

JWT (JSON Web Token) bestaat uit drie delen: Header, Payload en Signature. Lees meer over werken met JSON in Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

De server ondertekent het token; clients sturen het mee met aanvragen. De server valideert de handtekening zonder database-lookups.

24. Wat is het verschil tussen RS256 en HS256?

HS256 (symmetrisch): Dezelfde secret tekent en verifieert. Risico als meerdere services tokens moeten verifiëren.

RS256 (asymmetrisch): Privésleutel tekent, openbare sleutel verifieert. Aanbevolen voor gedistribueerde systemen waar meerdere services tokens valideren.

25. Wat is HATEOAS?

HATEOAS (Hypermedia as the Engine of Application State) betekent dat responses links bevatten naar gerelateerde acties en resources.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

In de praktijk implementeren de meeste API’s HATEOAS niet volledig. Ken het concept, maar verwacht niet dat je het in de meeste banen moet bouwen. Zelfs grote techbedrijven bouwen zelden volledig HATEOAS-conforme API’s.

26. Hoe ga je consistent om met fouten?

Gebruik het RFC 7807 Problem Details-formaat voor consistente foutresponses:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. Wat is rate limiting en waarom is het belangrijk?

Rate limiting beschermt je API tegen misbruik en zorgt voor eerlijk gebruik. Veelvoorkomende response:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. Hoe ontwerp je filtering en sortering?

Gebruik queryparameters met duidelijke conventies:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Geavanceerde REST API-sollicitatievragen

Deze vragen testen je architecturale denkwijze. Verwacht ze voor seniorfuncties.

29. Wat is er veranderd tussen OAuth 2.0 en OAuth 2.1?

OAuth 2.1 bundelt security best practices:

De kern: gebruik Authorization Code flow met PKCE voor alle clienttypen.

30. Hoe implementeer je idempotentie voor betaalendpoints?

Gebruik idempotency keys om POST-aanvragen veilig te maken voor retries:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

De client genereert een UUID en stuurt die mee met de aanvraag. Als dezelfde key opnieuw binnenkomt, retourneer je de gecachte response.

31. Hoe zou je een gedistribueerde rate limiter ontwerpen?

Voor gedistribueerde systemen kun je geen in-memory tellers gebruiken omdat verkeer via load balancing over instanties wordt verdeeld. Dit is een veelvoorkomende valkuil.

Architectuur:

1. Gebruik Redis voor gecentraliseerde telleropslag
2. Implementeer het Token Bucket-algoritme voor burst-tolerantie
3. Gebruik atomische operaties (Lua-scripts) om racecondities te voorkomen

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. Wanneer kies je voor gRPC in plaats van REST?

Kies gRPC voor:

• Interne microservice-communicatie (5-10x hogere throughput)
• Realtime streamingvereisten
• Mobiel-naar-backend met bandbreedtebeperkingen
• Polyglot-omgevingen die strikte contracten nodig hebben

Kies REST voor:

• Publieke API’s met diverse consumenten
• Webapplicaties (universele browserondersteuning)
• Eenvoudige CRUD-bewerkingen
• Teams die niet bekend zijn met Protocol Buffers

33. Hoe ga je om met langlopende operaties?

Gebruik het asynchrone aanvraagpatroon:

1. Client verstuurt aanvraag

2. Server retourneert 202 Accepted met een status-URL

3. Client pollt de status-URL tot voltooiing

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. Wat is het Saga-patroon?

Saga handelt gedistribueerde transacties over microservices af zonder locking. Elke service voert een lokale transactie uit en publiceert een event. Als een stap faalt, maken compenserende transacties eerdere stappen ongedaan.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. Wat zijn veelvoorkomende JWT-beveiligingslekken?

Algoritmeverwarring: aanvaller wijzigt RS256 naar HS256 en tekent met de openbare sleutel. Oplossing: whitelisten van algoritmen.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

"none"-algoritme: aanvaller verwijdert de handtekening volledig. Oplossing: "none"-algoritme afwijzen.

Backend Developer REST API-vragen

36. Wat is het N+1-queryprobleem?

Het N+1-probleem treedt op wanneer je N records ophaalt en vervolgens voor elke relatie van elk record een aparte query uitvoert.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Oplossingen:

Django: Gebruik select_related() voor foreign keys, prefetch_related() voor many-to-many.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy: Gebruik joinedload() of selectinload().

37. Hoe configureer je connection pooling?

Connection pooling hergebruikt databaseverbindingen in plaats van voor elke aanvraag nieuwe te maken.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. Welke cachingstrategieën ken je?

Er zijn drie primaire cachingstrategieën, elk geoptimaliseerd voor verschillende toegangsprofielen:

39. Hoe implementeer je verificatie van webhook-handtekeningen?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. Welke metrics duiden op API-gezondheid?

Je zou deze vier kernmetrics moeten monitoren om de gezondheid van je API te beoordelen:

Fullstack Developer REST API-vragen

41. Wanneer stuurt een browser een CORS-preflight-aanvraag?

Browsers sturen een OPTIONS-preflight voor:

• Methoden anders dan GET, HEAD, POST
• Aangepaste headers (Authorization, X-API-Key)
• Content-Type anders dan form-urlencoded, multipart/form-data, text/plain

42. Hoe configureer je CORS veilig?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Gebruik nooit wildcard (*) met credentials. Sta nooit null origin toe.

43. Waar sla je tokens op aan de clientzijde?

Tokenopslag kent security-trade-offs tussen XSS- en CSRF-kwetsbaarheden"

Best practice: Sla refresh-tokens op in HttpOnly-cookies met SameSite=Strict. Houd access tokens in memory.

44. Wanneer gebruik je WebSockets versus SSE?

De keuze hangt af van of je bidirectionele communicatie nodig hebt en hoe je reconnectie wilt afhandelen:

Gebruik SSE voor notificaties, live feeds, koersen. Gebruik WebSockets voor chat, multiplayer-games, collaboratieve bewerking.

45. Hoe ga je om met bestandsuploads?

Voor grote bestanden gebruik je chunked uploads met voortgangsrapportage:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Scenario-gebaseerde REST API-vragen

46. Ontwerp een REST-API voor een hotelboeksysteem

Resources:

• /hotels - Hotels weergeven en zoeken

• /hotels/{id}/rooms - Beschikbare kamers

• /bookings - Reserveringen aanmaken en beheren

• /guests/{id} - Gastenprofielen

Belangrijke keuzes:

• Gebruik cursor-gebaseerde paginering voor hotelzoekopdrachten
• Implementeer optimistische locking voor kamerbeschikbaarheid
• Retourneer 409 Conflict bij pogingen tot dubbele boeking
• Gebruik idempotency keys voor betalingsverwerking

47. Hoe zou je soft deletes implementeren?

Voeg een deleted_at timestamp toe in plaats van records te verwijderen:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. Hoe migreer je van v1 naar v2 zonder clients te breken?

Gebruik het Strangler Fig-patroon:

1. Implementeer v2 naast v1
2. Leid nieuwe features naar v2
3. Migreer geleidelijk bestaande endpoints
4. Communiceer deprecatie via de Sunset-header
5. Verwijder v1 na de migratieperiode

49. Hoe zou je een zoek-API ontwerpen met complexe filtering?

Voor een productzoekopdracht met meerdere filters:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Ontwerpbeslissingen:

• Gebruik Elasticsearch voor full-text search (relationele DB’s hebben moeite met fuzzy matching)
• Implementeer faceted search om beschikbare filteropties te tonen
• Retourneer filtertellingen zodat gebruikers zien hoeveel resultaten elke filter oplevert
• Cache populaire zoekcombinaties

50. Hoe ga je om met API-versiebeheer in een microservices-architectuur?

Opties:

1. Gateway-niveau versiebeheer: API-gateway routeert /v1/* naar oude services, /v2/* naar nieuwe

2. Service-niveau versiebeheer: Elke service handelt zijn eigen versieonderhandeling af

3. Consumer-driven contracts: Gebruik Pact of soortgelijke tools om compatibiliteit te waarborgen

Voor de meeste teams biedt versiebeheer op gateway-niveau de meest duidelijke scheiding.

51. Hoe zou je rate limiting implementeren voor verschillende gebruikersniveaus?

De oplossing omvat het definiëren van niveauspecifieke limieten en deze controleren met Redis-tellers:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Gedragsvragen over REST API’s

52. Leg REST uit aan een niet-technisch persoon

"Zie een REST-API als een ober in een restaurant. Jij (de klant) kunt niet direct de keuken in. In plaats daarvan vertel je de ober wat je van het menu wilt, en die brengt het naar je toe. Het menu is als de API-documentatie, met daarop wat je kunt bestellen. De ober volgt specifieke regels: je vraagt om iets (GET), je bestelt iets nieuws (POST), of je stuurt iets terug (DELETE). Als de keuken ergens doorheen is, vertelt de ober het je (404 Not Found) zodat je niet eindeloos wacht."

Deze analogie werkt verrassend goed in gesprekken met stakeholders.

53. Beschrijf een moment waarop je een API hebt geoptimaliseerd

Gebruik de STAR-methode:

• Situatie: "Onze zoek-API had reactietijden van 3 seconden tijdens piekverkeer"
• Taak: "Ik moest de latency verminderen zonder grote architectuurwijzigingen"
• Actie: "Ik heb Redis-caching toegevoegd voor veelvoorkomende queries, cursor-gebaseerde paginering geïmplementeerd en database-indexen toegevoegd"
• Resultaat: "Reactietijd daalde naar 200 ms en we verwerkten 5x meer verkeer"

54. Hoe communiceer je breaking changes aan API-consumenten?

1. Communiceer vroeg: Geef minstens 6-12 maanden vooraf bericht bij grote wijzigingen

2. Gebruik de Sunset-header: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Bied migratiegidsen: Documenteer exact wat verandert en hoe je je aanpast

4. Draai beide versies: Houd de oude versie actief tijdens de overgang

5. Monitor gebruik: Volg welke clients nog op de oude versie zitten

55. Welke documentatie maak je voor API’s?

Essentiële documentatie omvat:

• OpenAPI/Swagger-spec: Machineleesbaar contract
• Snelstartgids: Eerste API-call in minder dan 5 minuten
• Authenticatiegids: Hoe je credentials verkrijgt en gebruikt
• Foutenreferentie: Alle mogelijke foutcodes en hoe je ermee omgaat
• Changelog: Wat er in elke versie is veranderd
• Documentatie over rate limits: Limieten per niveau en hoe om te gaan met 429’s

56. Wanneer zou je GEEN REST gebruiken?

REST is niet altijd de juiste keuze. Weten wanneer je alternatieven inzet toont architecturale volwassenheid. Ik heb teams REST zien afdwingen in use-cases waar het meer problemen creëert dan oplost.

REST API Quick Reference

Gebruik deze sectie als snelle naslag wanneer je eigenschappen van HTTP-methoden, statuscodes of veelvoorkomende patronen wilt verifiëren tijdens je interviewvoorbereiding of in de praktijk.

Vergelijking van HTTP-methoden

Deze tabel vat de belangrijkste eigenschappen van elke HTTP-methode samen, helpt je de juiste te kiezen voor jouw use-case.

Statuscodes-referentie

Hier zijn de meest gebruikte HTTP-statuscodes, georganiseerd per categorie. Focus op wanneer je welke gebruikt in plaats van de volledige specificatie uit je hoofd te leren.

2xx Succes

• 200 OK: Geslaagde GET, PUT, PATCH
• 201 Created: Geslaagde POST (Location-header opnemen)
• 204 No Content: Geslaagde DELETE

4xx Clientfouten

• 400 Bad Request: Ongeldige syntaxis
• 401 Unauthorized: Authenticatie vereist
• 403 Forbidden: Geauthenticeerd maar niet geautoriseerd
• 404 Not Found: Resource bestaat niet
• 409 Conflict: Toestandsconflict
• 422 Unprocessable Entity: Validatiefout
• 429 Too Many Requests: Geraatelimiteerd

5xx Serverfouten

• 500 Internal Server Error: Generieke serverfout
• 502 Bad Gateway: Upstream-serverfout
• 503 Service Unavailable: Tijdelijk overbelast

Veelgemaakte fouten om te vermijden

Zelfs ervaren ontwikkelaars trappen hierin. Let op deze valkuilen bij het ontwerpen of implementeren van REST-API’s:

• Werkwoorden in URL’s gebruiken (bijv. /getUsers in plaats van /users)

• 200 OK retourneren voor fouttoestanden, wat client-side foutafhandeling breekt

• 401 en 403 verwarren (authenticatie vs. autorisatie)

• URL’s te diep nesten voorbij twee niveaus

• Tokens opslaan in localStorage (creëert XSS-kwetsbaarheden)

• Idempotentie negeren voor POST-aanvragen

• Generieke foutmeldingen retourneren zonder bruikbare details

Conclusie

Ik besef dat definities uit je hoofd leren niet garandeert dat je elk technisch interview haalt. De realiteit is dat engineering in de praktijk vaak vereist dat je de "strikte" regels die we net hebben besproken, doorbreekt, en interviewers geven meer om je redenering dan om je vermogen om RFC-specificaties op te dreunen. Voor zeer gespecialiseerde rollen kunnen diepere domeinkennis of specifieke frameworkexpertise alsnog doorslaggevend zijn.

Maar het beheersen van deze REST-basisprincipes is belangrijk, zelfs als je deze exacte vragen niet tegenkomt. Het dient als een blauwdruk om te begrijpen hoe het moderne web werkt. Wanneer je wordt gevraagd een nieuw systeem te ontwerpen of een storing in productie te debuggen, geeft het begrijpen van het onderscheid tussen een 401 en een 403 (zoals ik eerder uitlegde) je de helderheid om sneller problemen op te lossen. Je ziet precies waarom het standaardiseren van je API-interacties, en niet alleen code schrijven die werkt, het handelsmerk is van een senior engineer.

Wil je dieper duiken in het bouwen van deze systemen? Bekijk dan onze Introduction to APIs in Python-cursus.