Une API peut répondre vite, mais à côté : un objet d’erreur avec un statut 200, une liste vide ou une page de connexion. Un moniteur Website or API doté de contrôles de réponse détecte ces cas.
Créer le moniteur
Ouvrez Monitors, choisissez New monitor et sélectionnez Website or API.Saisissez l’URL de l’endpoint et choisissez la fréquence sous Check every.Dans la carte Request and response, choisissez Keyword, headers and more.
La requête
Method : GET, HEAD, POST, PUT, PATCH, DELETE ou OPTIONS.Request headers : un par ligne au format Name: value, par exemple une clé API ou Accept: application/json.Request body, par exemple du JSON pour un POST.Follow redirects, Verify TLS certificate et Timeout (s).
La réponse
Expected status codes : des codes ou des plages, comme 200-299, 301. Tout autre statut est considéré comme une panne.Keyword : un texte que la réponse doit, ou ne doit pas, contenir. La casse est prise en compte.Response checks : des champs JSON et des en-têtes, par exemple $.status égal à ok. Jusqu’à 10, et tous doivent être vérifiés.
Utilisez Test request pour voir la réponse avant d’enregistrer.
Réponses lentes et chronométrage
Renseignez Alert when slower than (ms), par exemple 2000. Quand trois vérifications d’affilée dépassent ce seuil, le moniteur passe à l’état lent et vos canaux reçoivent une alerte de lenteur ; le temps de lenteur ne compte pas comme indisponibilité. Le temps de réponse de chaque vérification est découpé en DNS, connexion, TLS, serveur et téléchargement, pour voir où le temps est passé. Voir les alertes en cas de réponses lentes.
API en plusieurs étapes
Quand un appel dépend d’un autre, par exemple une connexion pour obtenir un jeton, utilisez plutôt un parcours en plusieurs étapes.
Utilisez si possible un endpoint de santé dédié ; voir comment créer un endpoint de health check et la checklist de surveillance d’API. En savoir plus sur la surveillance d’API.