API-overvågning

Hvorfor har et API brug for sin egen overvågning

Et API er ikke bare en side under /api/. Det er en kontrakt. HTTP-metoden har betydning – GET vs POST ændrer semantikken. Headers bærer autentificering, content negotiation, idempotency nøgler. Request body er inputtet. Svarkoden betyder noget (401 vs 403 vs 422 – hver fortæller en anden historie). Svarens body har en struktur – JSON-stier, som integratorer er afhængige af. En almindelig uptime-check, der kun rammer URL’en med GET, overser de fleste måder, et API kan fejle på: ugyldig JSON der stadig returnerer 200, auth-endpoint der accepterer forkerte data, webhook med defekt payload-schema, endpoint der returnerer 200 men med "status": "error" indeni.

API-overvågning løser dette ved at give dig kontrol over hver del af requesten og hver del af valideringen af svaret. Du konfigurerer nøjagtigt det kald, som dine integratorer laver – samme metode, samme headers, samme body, samme auth – og præcist hvad succes betyder – nøjagtige koder, værdier under JSON-stier, svartidstærskler, størrelsesgrænser.

Konfiguration af forespørgslen

For hver API-monitor i DiagnoSEO Uptime Monitoring kan du konfigurere:

• HTTP-metode: GET, POST, PUT, PATCH, DELETE, HEAD. Vælg den, som integratorerne bruger.
• Egne headers: som et JSON-objekt, fx {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Standard til test af OAuth, JWT, API-nøgler, content negotiation.
• Request body: hvilken som helst streng – JSON, XML, form-encoded, ren tekst. Sendes ved POST/PUT/PATCH/DELETE.
• Basic auth: brugernavn og kodeord, hvis endpointet er beskyttet på den måde.
• Forventede statuskoder: liste eller interval. Som standard 200-399, men du kan stramme til én kode (fx præcis 201 for et create-endpoint) eller tillade specifikke (fx 200,202,204).

Checken følger op til 5 redirects, dekoder gzip, parser Content-Type for at opdage JSON. Hver check gemmer den faktiske kode, response-tid, størrelse og eventuel fejl. Flere på hinanden følgende fejl (konfigurerbart, standard 2) udløser en hændelse.

JSON path-assertioner

Statuskoder alene er ikke nok for mange API'er. Et health-endpoint kan returnere 200 med body {"status": "degraded", "db": "down"} – det er stadig 200, men det vil du absolut vide. Et pris-API kan returnere 200 med en body, hvor data.price er faldet til null. Et søge-API kan returnere 200 med results: [], fordi indekset er nede.

I sådanne tilfælde konfigurer en JSON path assertion. Indstil stien (fx data.status eller health.checks.db) og den forventede værdi (fx healthy, true eller et specifikt tal). Ved hver check dekodes svaret fra JSON og værdien under stien sammenlignes. Manglende match afslutter checken som fejl, uanset HTTP-status.

Stiens syntaks er dotnotation med paranteser: data.items[0].id virker, ligesom users.john.email. Den asserted værdi sammenlignes som en streng, så "true" matcher bool true, og tal matcher både som streng og tal.

Autentificeringsmønstre

De to mest almindelige auth-typer virker out of the box. For Bearer-token (OAuth, JWT, API-nøgler) brug header-feltet: {"Authorization": "Bearer eyJhbGciOi..."}. Tokenen er gemt i monitor-konfigurationen og sendes ved hver check. For basic auth bruges dedikerede felter brugernavn/kodeord – de gemmes og sammenflettes til standard-headeren.

Hvis auth kræver per-request signering eller fornyelse af token, er det sværere. To fornuftige mønstre: (1) konfigurer en langtidsholdbar servicekonto-token specielt til overvågning, eller (2) udstil et ikke-autentificeret health-endpoint, som spejler status på det rigtige beskyttede, og overvåg dét. De fleste moderne API'er har allerede denne mulighed.

Mønstre vi anbefaler

• Én monitor per kritisk endpoint. Test ikke alt – vælg 5-10, hvor fejl ville forårsage reel skade.
• Brug præcise koder. Standard 200-399 er for tilladende for API. Create-endpoint skal returnere præcis 201; idempotent præcis 200; login-endpoint præcis 200 (succes) eller 401 (veldefineret fejl – ikke 500).
• Kombiner status med JSON-assertion. Sammen fanger de regressioner både i transport- og contentlag. Status alene fanger ikke content-fejl; kun JSON-assertion er skrøbelig ved redirects.
• Sæt tærskel for svartid. API-degradering er et tidligt tegn på afhængighedsproblemer. En monitor med rt_threshold_ms = 800 viser, at API'et bliver langsomt før det går ned.
• Hold body lille. Checket kører hvert minut – store body’er spilder båndbredde på begge sider. Repræsentative men minimale payloads er nok.

Kombinér med andre monitortyper

For hvert API-endpoint verificerer API-monitoren, at kaldet virker. En separat ping- eller port-monitor bekræfter, at værten lever. SSL/domaine-check på samme hostname fanger problemer med certifikat og registrering. En DNS sub-monitor holder øje med ændringer i records, der kunne signalere ændring. Fire monitors for et API giver samlet overblik med minimal overlap.

Konfiguration

Åbn værktøjet, klik på "Tilføj monitor", vælg type "API". Indsæt URL. Åbn sektionen Avanceret. Vælg metode, indsæt headers som JSON, indsæt body hvis nødvendigt, opsæt basic auth hvis du bruger det, indtast forventede koder (fx 200 eller 200,201). Tilføj JSON path assertion hvis det er relevant. Sæt interval og bekræftelsestærskel. Gem. Allerede fra næste cyklus kalder monitoren dit API nøjagtig som en integrator ville, validerer svaret og advarer straks ved regression.

Ofte stillede spørgsmål

• Hvilke HTTP-metoder kan jeg bruge til at overvåge API?

  GET, POST, PUT, DELETE, PATCH og HEAD. Konfigurer metoden for hver monitor — for write-endpoints (POST/PUT/PATCH) er request body også konfigurerbar som JSON-streng eller form data.

• Hvordan fungerer JSON-assertioner?

  Du angiver en JSON-sti (fx data.status eller results[0].id) og den forventede værdi. Monitoren henter svaret, parser som JSON, ekstraherer stien og sammenligner med det forventede. Hvis de ikke matcher, fejler checken med fejlen "assertion failed" og viser den faktiske værdi.

• Kan jeg sende autentificeringsheaders?

  Ja. Custom HTTP-headers kan konfigureres per monitor — Authorization-tokens, API-nøgler, content-type, hvad som helst. Header-værdier krypteres i hvile i databasen. For Basic Auth er der dedikeret felt til brugernavn/kodeord, som automatisk signerer requestet.

• Hvad hvis mit API returnerer 200 med en fejl-payload?

  Et udbredt mønster: API returnerer HTTP 200 men body siger {"status":"error"}. En naiv uptime-monitor tror det er sundt. Brug JSON-assertion status == "ok" for at fange det — assertion fejler og monitoren rapporterer NED selvom HTTP siger 200.

• Hvordan håndterer jeg et API med rate limit?

  Sæt check-intervallet så det respekterer API-grænsen (fx 5-minutters interval hvis API tillader 12 kald/time). Monitoren tæller som ét API-kald per check fra én region. Multi-region checks ganger antal kald — brug single-region hvis dit API har strikte begrænsninger.