Documentation

Vérifier le contenu des réponses : JSON, XML, HTML et en-têtes

Un serveur qui répond 200 OK avec une page d’erreur, une liste vide ou les données de la veille est disponible du point de vue du code de statut — et pourtant en panne pour tous ceux qui l’utilisent. Pour une surveillance de site web ou d’API digne de ce nom, Pingsured peut vérifier ce que contient une réponse, et pas seulement qu’elle est arrivée.

Toutes les vérifications ci-dessous sont facultatives et se combinent librement. Un ping ne réussit que si le code de statut correspond et si toutes les vérifications de contenu que vous avez configurées réussissent.

Code de statut

Le statut attendu est un code unique, une liste ou une plage : 200, 200,204 ou 200-299. Toute autre réponse est un échec. La valeur par défaut est 200.

Texte dans le corps de la réponse

La vérification de contenu la plus simple : le corps de la réponse doit contenir un fragment de texte, par exemple le nom d’un produit ou le marqueur « healthy » qu’affiche votre point de terminaison de santé. Il s’agit d’une simple recherche de sous-chaîne, de 1 024 caractères au plus.

Champs JSON (JSONPath)

Pour les API, sélectionnez une valeur avec une expression JSONPath et comparez-la. Par exemple, un point de terminaison de santé qui répond {"status": "ok", "queue": {"depth": 12}} peut être vérifié ainsi :

Opérateurs disponibles :

• existe / n’existe pas — le chemin sélectionne quelque chose, ou rien.
• égal à / différent de — comparaison typée : le nombre 12 n’est pas égal à la chaîne "12".
• contient et correspond à (une expression régulière) pour le texte.
• supérieur / inférieur à (ou égal) pour les nombres.
• comparaisons de nombre de correspondances, par exemple « au moins un élément dans $.items[*] ».
• comparaisons d’âge pour les horodatages, décrites plus bas dans la partie sur la fraîcheur.

Lorsqu’un chemin sélectionne plusieurs valeurs, c’est la première qui est comparée. Jusqu’à 16 vérifications JSON par ping.

Éléments XML (XPath)

Même principe pour les réponses XML — flux, services SOAP, sitemaps — avec des expressions XPath comme /rss/channel/item (nombre au moins égal à 1) ou //status/text() (égal à ok). Les opérateurs sont existe, n’existe pas, égal à, contient, correspond à, les comparaisons de nombre et les comparaisons d’âge. Une réponse qui n’est pas du XML bien formé fait échouer toutes les vérifications XML.

Éléments HTML (sélecteurs CSS)

Pour les pages web, ciblez un élément avec un sélecteur CSS — ou une expression XPath, si vous préférez — et vérifiez son texte ou l’un de ses attributs. Le texte est comparé après normalisation des espaces, si bien que les retours à la ligne du balisage n’ont pas d’importance. Usages typiques :

• l’élément de prix d’une fiche produit existe et n’est pas vide ;
• h1.title contient votre titre, ce qui permet de repérer un gabarit vide ou une page de maintenance ;
• l’attribut content d’une balise meta a la valeur attendue.

En-têtes de réponse

Deux façons de vérifier les en-têtes : une correspondance exacte par en-tête, ou les mêmes opérateurs que ci-dessus — existe, n’existe pas, égal à, contient, correspond à, comparaisons numériques et comparaisons d’âge. Les vérifications d’en-têtes ne lisent pas le corps de la réponse.

Fraîcheur : les données sont-elles à jour ?

Les opérateurs d’âge lisent une valeur comme un horodatage et comparent son ancienneté, en secondes. « $.updated_at âge inférieur à 3600 » échoue dès que les données les plus récentes ont plus d’une heure — le cas classique d’un export, d’un cache ou d’un flux qui a discrètement cessé de se mettre à jour alors que le serveur continue de répondre.

Formats reconnus :

• ISO 8601 / RFC 3339, par exemple 2026-10-09T14:30:00Z (une heure sans fuseau est lue en UTC) ;
• dates HTTP, si bien qu’un en-tête Last-Modified fonctionne tel quel ;
• temps Unix en secondes ou en millisecondes.

Limites à connaître

• Le corps de la réponse est lu jusqu’à 1 Mo.
• Les vérifications envoient des requêtes GET ou HEAD. Les autres méthodes et les corps de requête ne sont pas encore disponibles : ils peuvent modifier des données sur le serveur vérifié, et nécessiteront donc d’abord que vous prouviez que le domaine vous appartient.
• Vous pouvez ajouter jusqu’à 20 en-têtes de requête ainsi qu’une authentification HTTP basique, pour les points de terminaison qui exigent un jeton ou un identifiant.
• Le User-Agent est toujours Pingsured/1.0, avec un lien vers la page qui explique nos requêtes aux exploitants de serveurs.