API-övervakning

Varför behöver API:er egen övervakning

Ett API är inte bara en sida på /api/. Det är ett avtal. HTTP-metoden spelar roll – GET vs POST ändrar semantiken. Headers bär på autentisering, innehållsförhandling, idempotensnycklar. Request-body är input. Statuskoder spelar roll (401 vs 403 vs 422 – alla berättar olika historia). Svarsbody har struktur – JSON-paths som integratörer förlitar sig på. En enkel uptimetest som bara gör GET på URL:en missar de flesta sätt ett API kan gå sönder: ogiltig JSON som ändå returnerar 200, auth-endpoint som accepterar felaktiga data, webhook med trasig payloadschema, endpoint som ger 200 men med "status": "error" i svaret.

API-övervakning löser detta genom att ge dig kontroll över varje del av requesten och varje del av responsvalideringen. Du konfigurerar exakt det anrop som dina integratörer gör – samma metod, samma headers, samma body, samma auth – och exakt vad som räknas som framgång – exakta koder, värden under JSON-paths, svarstidströsklar, storleksgränser.

Requestkonfiguration

För varje API-monitor i DiagnoSEO Uptime Monitoring kan du konfigurera:

• HTTP-metod: GET, POST, PUT, PATCH, DELETE, HEAD. Välj den som dina integratörer använder.
• Egna headers: som ett JSON-objekt, t.ex. {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Standard för att testa OAuth, JWT, API-nycklar, content negotiation.
• Request-body: valfri sträng – JSON, XML, form-encoded, plain text. Skickas med POST/PUT/PATCH/DELETE.
• Basic auth: användarnamn och lösenord, om endpointen är skyddad på det sättet.
• Förväntade statuskoder: lista eller intervall. Som standard 200-399, men du kan snäva in till en enda kod (t.ex. exakt 201 för skapande-endpoint) eller tillåta specifika (t.ex. 200,202,204).

Kontrollen följer max 5 redirects, avkodar gzip, tolkar Content-Type för att hitta JSON. Varje kontroll loggar faktisk kod, svarstid, storlek och eventuellt fel. Flera på varandra följande fel (konfigurerbart, standard 2) utlöser ett incident.

JSON path-assertioner

Bara statuskoder räcker inte för många API:er. En health-endpoint kan returnera 200 med body {"status": "degraded", "db": "down"} – fortfarande 200, men det vill du absolut veta. Ett pris-API kan returnera 200 med body där data.price har blivit null. Ett sök-API kan returnera 200 med results: [] för att indexet är nere.

För sådana fall – konfigurera JSON-path-assertion. Ange path (t.ex. data.status eller health.checks.db) och förväntat värde (t.ex. healthy, true eller ett specifikt tal). Vid varje kontroll tolkas svaret som JSON och värdet på path jämförs. Avvikelse gör att kontrollen klassas som fel, oavsett HTTP-status.

Paths skrivs med punktnotation och hakparenteser: data.items[0].id funkar, liksom users.john.email. Det förväntade värdet jämförs som sträng – så "true" matchar bool true, och siffror matchar både som string och som number.

Autentiseringsmönster

De två vanligaste auth-stilarna stöds direkt. För Bearer-tokens (OAuth, JWT, API-nycklar): använd headers-fältet: {"Authorization": "Bearer eyJhbGciOi..."}. Token lagras i monitor-konfigurationen och skickas vid varje kontroll. För basic auth använder du separata fält för användarnamn/lösenord – de sparas och sätts ihop till standardheadern.

Om auth kräver signering per request eller att token förnyas varje gång, blir det svårare. Två rimliga mönster: (1) konfigurera en långlivad tjänstekontotoken speciellt för övervakning, eller (2) ha ett oautentiserat health-endpoint som speglar statusen för den skyddade och övervaka den. De flesta moderna API har detta redan ut-of-the-box.

Mönster vi rekommenderar

• En monitor per kritisk endpoint. Testa inte alla – välj ut 5-10 där en incident innebär verkligt problem.
• Använd exakta koder. Standard 200-399 är för tillåtande för API:er. Skapande-endpoint bör ge exakt 201; idempotenta exakt 200; login-endpoint exakt 200 (OK) eller 401 (välformulerat fel – inte 500).
• Kombinera status med JSON-assertion. Tillsammans fångar de regressioner både i transportskiktet och content. Status ensam ser inte content-fel; JSON-assertion ensam är ömtålig vid redirect.
• Sätt svarstidströskel. API-degradering är en tidig indikator på beroendeproblem. En monitor med rt_threshold_ms = 800 berättar att API:t blir långsamt innan det kraschar.
• Håll body liten. Kontroll sker varje minut – stora body slösar bandbredd på båda sidor. Representativa men minimala payloads räcker.

Kombinera med andra monitortyper

För varje API-endpoint bekräftar en API-monitor att anropet fungerar. En separat ping- eller port-monitor bekräftar att hosten är uppe. SSL-/domänmonitor på samma hostname fångar certifikat- och registerproblem. DNS-submonitor bevakar ändringar som kan tyda på kapning. Sammanlagt ger fyra slags monitorer för ett API full översikt med minimal överlappning.

Konfiguration

Öppna verktyget, klicka på "Lägg till monitor", välj typ "API". Klistra in URL. Öppna Avancerat. Välj metod, klistra in headers som JSON, klistra in body vid behov, sätt basic auth om du använder det, ange förväntade koder (t.ex. 200 eller 200,201). Lägg till JSON path-assertion om det är relevant. Sätt intervall och bekräftelsetröskel. Spara. Från nästa cykel testar monitorn ditt API exakt som en integratör hade gjort, validerar svaret och larmar direkt vid regression.

Vanliga frågor

• Vilka HTTP-metoder kan jag använda för API-övervakning?

  GET, POST, PUT, DELETE, PATCH och HEAD. Välj metod per monitor — för write-endpoints (POST/PUT/PATCH) kan request-body också konfigureras som JSON-sträng eller form data.

• Hur fungerar JSON-assertioner?

  Du anger en JSON-path (t.ex. data.status eller results[0].id) och förväntat värde. Monitorn hämtar svaret, tolkar det som JSON, extraherar path och jämför med det förväntade. Om de inte matchar misslyckas checken med felet "assertion failed" och visar det faktiska värdet.

• Kan jag skicka autentiseringsheaders?

  Ja. Anpassade HTTP-headers kan konfigureras per monitor — Authorizations-tokens, API-nycklar, content-type, vad du vill. Header-värden krypteras i vila i databasen. För Basic Auth finns separata fält för användarnamn/lösenord som automatiskt signerar requesten.

• Vad om mitt API returnerar 200 med en felpayload?

  Vanligt mönster: API:t returnerar HTTP 200 men body visar {"status":"error"}. En naiv uptimemonitor tror det är OK. Använd JSON-assertion status == "ok" för att upptäcka detta – assertionen misslyckas och monitorn rapporterar NERE även om HTTP säger 200.

• Hur hanterar jag API med rate limit?

  Sätt checkintervall för att respektera API:ets limit (t.ex. 5-minutersintervall om API:t tillåter 12 anrop/timme). Varje check från en region räknas som ett API-anrop. Multi-region-checkar multiplicerar antalet anrop – använd single-region om din API har hård limit.