Een API achter een login monitoren

Monitor een API die achter een login zit, zodat je echte storingen opmerkt — niet alleen een statuspagina die "OK" zegt terwijl de onderdelen die ertoe doen kapot zijn. Dit is voor iedereen die een API moet controleren waarvoor je eerst moet inloggen.

#Overzicht

• Een statuspagina kan er prima uitzien, zelfs als inloggen, tokens of de eigenlijke data-aanroepen mislukken.
• Een API-monitor gedraagt zich als een echte gebruiker: hij logt in, bewaart het token dat hij terugkrijgt en gebruikt dat token om je API aan te roepen.
• Als een stap mislukt, gaat de monitor down en vertelt precies welke stap mislukte en waarom — bijvoorbeeld "Step 2 of 3 (GET /orders): HTTP 401".

#Instellen

1. Ga naar Monitoring en klik op Add monitor.
2. Klik op Advanced monitors en kies vervolgens API monitor.
3. Vul het eerste verzoek in — meestal je inlogadres — met de bijbehorende methode en request body. Dit verzoek is stap 1.
4. Geef onder Save from this response de waarde een naam die je later nodig hebt (bijvoorbeeld token), kies waar deze vandaan komt en geef aan waar je hem kunt vinden:
   • JSON field — een pad zoals $.access_token;
   • Response header — een headernaam zoals X-Session-Id;
   • Pattern in the text — een patroon waarvan de eerste groep de waarde is, zoals token=([a-z0-9]+).
5. Voeg onder Secret values alles toe wat je niet opnieuw wilt hoeven bekijken, zoals het wachtwoord dat bij het inloggen wordt gebruikt. Schrijf vervolgens {{password}} in de body van stap 1 op de plek van het wachtwoord.
6. Klik op Add a step voor elk volgend verzoek. Geef een methode en een adres op — een volledig adres, of gewoon een pad zoals /orders, dat wordt gelezen ten opzichte van het adres van de monitor — en gebruik opgeslagen waarden met dubbele accolades, bijvoorbeeld een header Authorization met de waarde Bearer {{token}}. Het waardeveld toont alle waarden die de stap kan gebruiken.
7. Stel voor elke stap de statuscodes in die als succesvol gelden en, als je dat wilt, controles op de JSON die wordt teruggegeven.
8. Klik op Test connection om de hele flow één keer te proberen en sla daarna op.

#Wat je ervoor terugkrijgt

• De monitor is alleen up als elke stap slaagt. De eerste stap die mislukt, beëindigt de controle, en de reden benoemt de stap, het verzoek en wat er misging. Meldingen en incidenten gebruiken dezelfde bewoordingen.
• Op de pagina van de monitor toont Steps elk verzoek dat tijdens de laatste controle is gedaan, met de teruggekregen status en de duur ervan.
• Regio's, hoeveel locaties het eens moeten zijn en failover werken precies zoals bij elke andere monitor.

#Goed om te weten

• Maximaal 5 stappen in totaal, inclusief het eerste verzoek, en maximaal 5 opgeslagen waarden per stap.
• Alle stappen samen krijgen maximaal 60 seconden, en nooit meer dan het interval van de monitor. Een stap die na die tijd zou starten, wordt gerapporteerd als "ran out of time".
• Secret values worden versleuteld opgeslagen en nooit opnieuw getoond — niet in het formulier, niet via de API. Om er een te wijzigen, typ je een nieuwe waarde; om er een te verwijderen, haal je hem weg en sla je op.
• Opgeslagen waarden worden nooit bewaard. De stappenlijst toont elk verzoek zoals je het hebt geschreven (/orders/{{order_id}}), niet met de waarden ingevuld, en een waarde die in een foutmelding voorkomt, wordt vervangen door [hidden].
• De eigen inloginstellingen van de monitor (basic, digest of bearer) worden alleen naar stappen op dezelfde site als het adres van de monitor gestuurd. Zet alles wat een stap op een andere site nodig heeft in de headers van die stap.

WarningHeaders die een wachtwoord, sleutel of token bevatten — Authorization, Cookie, X-Api-Key en dergelijke — moeten een waarde gebruiken zoals {{api_key}} of Bearer {{token}}. Zet het wachtwoord of de sleutel in Secret values en verwijs ernaar; het rechtstreeks typen ervan in de header wordt geweigerd bij het opslaan.

#Problemen oplossen

• "… has no value" — een stap gebruikt een naam die door geen eerdere stap is opgeslagen en die geen secret value heeft. Controleer de spelling en of de stap die de waarde opslaat eerder komt.
• "Couldn't save …" — het antwoord bevatte niet wat je had aangewezen. Voer Test connection uit en vergelijk het pad met wat je API daadwerkelijk teruggeeft.
• "Step 1 of 2 …: HTTP 401" — het inloggen zelf werd geweigerd. Controleer de secret value en de request body.

TipGebruik Test connection na elke wijziging aan de stappen — het voert de hele flow één keer uit, zodat je een kapotte login of een verkeerd pad kunt opsporen voordat je opslaat.