API-monitoring: wanneer HTTP 200 niet genoeg is

Een JSON-API kan HTTP 200 teruggeven met een fout in de body - monitoring op statuscode meldt UP. Echte API-monitoring controleert ook de inhoud van het antwoord, niet alleen de HTTP.

Het probleem: HTTP 200 != werkende API

Volgens de REST API-conventies moeten statuscodes correct worden gebruikt (200 OK, 4xx client error, 5xx server error). In de praktijk:

Sommige API's geven altijd 200 terug, de fout zit in de JSON-body
Een API-gateway kan een 5xx omzetten naar een 200 met error-JSON
Frontend-BFF-endpoints wrappen vaak backends en geven 200 terug als de communicatie is gelukt, zelfs wanneer de backend faalde
GraphQL-endpoints geven doorgaans 200 terug; fouten (errors) staan in de array errors[]

Vanuit het perspectief van klassieke monitoring (HTTP-statuscode) is alles in orde. Vanuit het perspectief van een echte client is de API stuk.

Content matching: trefwoorden

De eenvoudigste aanvulling op HTTP-monitoring is een trefwoord-match. Je definieert een string die in het antwoord moet staan - ontbreekt die, dan komt er een melding.

Voorbeeld voor een health check-endpoint:

GET /api/health HTTP/1.1

{
  "status": "ok",
  "checks": {
    "database": "ok",
    "redis": "ok",
    "queue": "ok"
  },
  "version": "1.42.3"
}

Stel de keyword match in op "status":"ok". Als de DB uitvalt en het endpoint "status":"degraded" teruggeeft, vangt de monitoring het op.

Negative matching: wat zou moeten ontbreken

Soms is het nuttiger om te controleren dat een bepaalde string NIET in het antwoord staat:

"error" - een fout in de body
"maintenance" - een onverwachte onderhoudsmodus
"deprecated" - het API-endpoint is gemarkeerd als verouderd (deprecated)
SQL-foutfragmenten: "SyntaxError", "undefined", "null pointer" - uitlekkende backend-fouten

Geavanceerde asserties

Plain text matching heeft zijn grenzen. Voor serieuze API-monitoring zijn gestructureerde asserties over de JSON-structuur (JSONPath-expressies) en synthetische transacties met meerdere stappen (login -> beschermd endpoint -> logout) het juiste gereedschap.

ePulz.io ondersteunt deze opties rechtstreeks. Multi-step / API-monitoring laat je tot 10 stappen ketenen (GET/POST/PUT/PATCH/DELETE/HEAD), bij elke stap de statuscode, de inhoud en een JSONPath-waarde verifieren, en variabelen uit het antwoord opslaan voor volgende stappen. De functie is beschikbaar in de plannen Profi en Business en draait op de primaire regio. Voor eenvoudigere gevallen in lagere plannen kun je een HTTP-monitor combineren met een apart hulpscript dat het resultaat verstuurt via een heartbeat-monitor.

Authentication in monitoring

Een gemonitord endpoint vereist vaak auth. Opties:

Bearer token in de Authorization-header - meestal een long-lived monitoring-token zonder vervaldatum (veilig opslaan)
API key in een query-parameter - zichtbaar in de logs, niet de voorkeur
HMAC-handtekening - timestamp + URL + body-hash ondertekend met een shared secret. Het veiligst.
mTLS - een client-certificaat aan de monitoring-kant. Geschikt voor interne API's.

Beveiligingsmelding: Maak voor monitoring een toegewijd account / token aan met minimale rechten (read-only health-endpoint, geen admin-token). Roteer het token regelmatig. Als de monitoring-service wordt gecompromitteerd, lekt niet de volledige toegang tot de API.

Responstijd-SLO

De responstijd van de API is net zo belangrijk als de HTTP-code. Een client met een timeout van 30 s ziet geen verschil tussen "de API geeft 200 terug in 25 s" en "de API liep in een timeout". Vanuit UX-oogpunt zijn beide slecht.

Stel in:

Hard timeout - na 10-15 s meldt de monitoring DOWN
Soft threshold - een responstijd tussen 500-2000 ms = warning (degraded performance)
Trendmeldingen - een melding als het 95e percentiel van de responstijd met 50 % stijgt in de afgelopen 24 h

Per-endpoint monitoring

Een grote API heeft tientallen endpoints. Monitor niet alleen /health - ook die kan liegen. Identificeer 3-5 kritieke endpoints:

De meest gebruikte business operations (POST /api/orders, GET /api/dashboard)
Een lees-endpoint dat een cache hit test (snel antwoord)
Een schrijf-endpoint met een DB-roundtrip
Een external integration-endpoint (roept een derde partij aan - detecteert uitval van afhankelijkheden)

Monitor elk apart. Bij een incident zie je zo precies welk deel van de API is uitgevallen.

Conclusie

API-monitoring kan niet worden teruggebracht tot een HTTP-statuscode. Kwalitatieve monitoring combineert status + content match + responstijd + per-endpoint granulariteit + authentication, om een echte client trouw na te bootsen - niet alleen een HTTP-client.

API-monitoring met trefwoord-matching

Statuscode + trefwoord in de inhoud + responstijd + auth headers. Per-endpoint granulariteit.

Monitoring starten →