API-overvåking

Hvorfor API-er trenger egen overvåkning

Et API er ikke bare en side under /api/. Det er en kontrakt. HTTP-metoden har betydning – GET vs POST endrer semantikken. Headers bærer autentisering, content negotiation, idempotens-nøkler. Forespørselskroppen er input. Svar-koden har en betydning (401 vs 403 vs 422 – alle forteller en annen historie). Respons-body har struktur – JSON-paths integratorer stoler på. En enkel uptime-sjekk som bare sender en GET til URL, overser de fleste måter et API kan feile på: ugyldig JSON som fortsatt returnerer 200, autentiseringsendepunkt som godtar feil data, webhook med ødelagt payload-skjema, endepunkt som returnerer 200 men med "status": "error" inni.

API-overvåking løser dette ved å gi deg kontroll over hver del av forespørselen og hver del av responsvalideringen. Du konfigurerer eksakt den kallet integratorene dine gjør – samme metode, samme headers, samme body, samme auth – og eksakt hva som betyr suksess – eksakte koder, verdier under JSON-paths, responstidsgrenser, størrelsesbegrensninger.

Request-oppsett

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

• HTTP-metode: GET, POST, PUT, PATCH, DELETE, HEAD. Velg den integratorene bruker.
• Egne headers: som et JSON-objekt, f.eks. {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Standard for testing av OAuth, JWT, API-nøkler, content negotiation.
• Request-body: en hvilken som helst streng – JSON, XML, form-encoded, ren tekst. Sendes ved POST/PUT/PATCH/DELETE.
• Basic auth: brukernavn og passord hvis endepunktet er sikret på denne måten.
• Forventede statuskoder: liste eller intervall. Standard er 200–399, men du kan snevre inn til én kode (f.eks. akkurat 201 for opprettelses-endepunkt) eller tillate bestemte (f.eks. 200,202,204).

Sjekken følger maks. 5 redirects, dekoder gzip, parser Content-Type for å oppdage JSON. Hver sjekk lagrer faktisk kode, responstid, størrelse og eventuelle feil. Flere påfølgende feil (konfigurerbart, standard 2) utløser en hendelse.

JSON path asserter

Alene er statuskoder ikke nok for mange API-er. Health-endepunkt kan returnere 200 med body {"status": "degraded", "db": "down"} – fortsatt 200, men du vil absolutt vite det. Pris-API kan returnere 200 med body der data.price har blitt null. Søke-API kan returnere 200 med results: [] fordi indeksen er nede.

For slike tilfeller, konfigurer JSON path-asert. Angi en path (f.eks. data.status eller health.checks.db) og forventet verdi (f.eks. healthy, true eller et spesifikt tall). Ved hver sjekk dekodes svaret fra JSON, og verdien under pathen sammenlignes. Uoverensstemmelse fører til feilet sjekk, uansett HTTP-status.

Path-syntaks er punktnotasjon med klammeparenteser: data.items[0].id fungerer, det samme gjør users.john.email. Asert-verdien sammenlignes som streng, så "true" matcher bool true, og tall matcher både som strenger og tall.

Autentiseringsmønstre

De to vanligste auth-mønstrene fungerer ut av boksen. For Bearer-tokens (OAuth, JWT, API-nøkler) bruk headers-feltet: {"Authorization": "Bearer eyJhbGciOi..."}. Token ligger i monitor-konfigen og sendes ved hver sjekk. For basic auth bruk det dedikerte brukernavn/passord-feltet – de lagres og kombineres i standard header.

Hvis auth krever signering per forespørsel eller refresh av token, er det mer krevende. To anbefalte mønstre: (1) konfigurer et langlevende servicekonto-token spesielt for overvåking, eller (2) gjør et uautentisert health-endepunkt tilgjengelig som gjenspeiler status for den beskyttede ekte, og overvåk det. De fleste moderne API-er har allerede dette ut av boksen.

Mønstre vi anbefaler

• Én monitor per kritisk endepunkt. Ikke test alt – velg 5–10 der feil ville ha reelle konsekvenser.
• Bruk nøyaktige koder. Standard 200–399 er for bredt for API. Opprettelses-endepunkt bør returnere nøyaktig 201; idempotente nøyaktig 200; login-endepunkt nøyaktig 200 (suksess) eller 401 (well-formed feil – ikke 500).
• Kombiner status med JSON asserter. Sammen fanger de regresjoner både i transport- og innholdslaget. Status alene tar ikke content-feil; JSON-assert alene er sårbar ved redirects.
• Sett responstidsgrense. Degradering i API-et er et tidlig signal om avhengighetsproblemer. En monitor med rt_threshold_ms = 800 varsler at API-et slakker før det faller ned.
• Hold body liten. Sjekken går hvert minutt – store body-er sløser båndbredde på begge sider. Reprensentative, men minimale payloads holder.

Kombiner med andre monitortyper

For hvert API-endepunkt verifiserer en API-monitor at kallet fungerer. En separat ping- eller portmonitor verifiserer at verten lever. SSL-/domene-sjekk på samme hostname fanger sertifikat- og registreringsproblemer. En DNS-submonitor passer på endringer i oppføringer som kan tyde på kapring. Samlet gir fire monitorer på et API full oversikt med minimal overlapp.

Oppsett

Åpne verktøyet, klikk "Legg til monitor", velg type "API". Lim inn URL. Åpne Avanserte-innstillinger. Velg metode, lim inn headers som JSON, lim inn body hvis aktuelt, sett basic auth hvis brukt, skriv inn forventede koder (f.eks. 200 eller 200,201). Legg til JSON path-assert hvis den gjelder. Sett intervall og bekreftelsesterskel. Lagre. Fra neste syklus slår monitoren mot ditt API eksakt slik en integrator ville gjort, validerer responsen og varsler umiddelbart ved regresjon.

Ofte stilte spørsmål

• Hvilke HTTP-metoder kan jeg bruke for API-overvåking?

  GET, POST, PUT, DELETE, PATCH og HEAD. Du konfigurerer metode per monitor — for write-endepunkt (POST/PUT/PATCH) er request-body også konfigurerbar som JSON-streng eller form-data.

• Hvordan fungerer JSON asserter?

  Du angir en JSON-path (f.eks. data.status eller results[0].id) og en forventet verdi. Monitoren henter svaret, parser som JSON, ekstraherer path og sammenligner med forventet. Dersom det ikke samsvarer, feiler sjekken med feilen "assertion failed" som viser faktisk verdi.

• Kan jeg sende autentiseringsheaders?

  Ja. Egendefinerte HTTP-headers konfigureres per monitor – Authorization tokens, API-nøkler, content-type; hva som helst. Header-verdier krypteres i ro i databasen. For Basic Auth har du et dedikert brukernavn/passord-felt som signerer forespørselen automatisk.

• Hva om mitt API returnerer 200 med feil-payload?

  Vanlig mønster: API returnerer HTTP 200 men body sier {"status":"error"}. En naiv uptime-monitor tror det er friskt. Bruk JSON-assert status == "ok" for å fange dette – asserten feiler og monitoren rapporterer NED selv om HTTP sier 200.

• Hvordan håndterer jeg API-er med rate limit?

  Sett sjekkeintervall for å respektere API-grensen (f.eks. 5-minutters intervall hvis API-et tillater 12 kall/time). En monitor teller som ett API-kall per sjekk fra en region. Multi-region sjekker multipliserer antall kall – bruk single-region dersom ditt API har strenge begrensninger.