Surveillance des API Web : Choisir le bon protocole

Dotcom-Monitor prend en charge REST, SOAP, GraphQL, gRPC, WebSockets et Webhooks. Les moniteurs REST valident les assertions JSONPath et les méthodes HTTP. Les moniteurs SOAP analysent le WSDL et valident le XML avec XPath. Les moniteurs GraphQL gèrent les requêtes, les mutations et les structures de données imbriquées. Les moniteurs gRPC décodent les réponses Protobuf. Les moniteurs WebSocket suivent les flux de messages bidirectionnels. Les moniteurs Webhook vérifient la livraison et la logique de réessai.

Les moniteurs à étapes multiples enchaînent jusqu’à 20 appels API en séquence. Chaque étape peut extraire des données de la réponse précédente en utilisant JSONPath ou XPath, puis les transmettre à la requête suivante en tant qu’en-tête, paramètre de requête ou champ de corps. Par exemple, l’étape 1 pourrait POST à /login et extraire un jeton JWT, l’étape 2 utilise ce jeton dans l’en-tête Authorization pour GET /cart, et l’étape 3 utilise l’ID du panier de l’étape 2 pour POST /checkout. Chaque étape suit le timing, les codes d’état et les charges utiles de réponse de manière indépendante.

Dotcom-Monitor prend en charge OAuth 2.0 (avec actualisation automatique du jeton), JWT, clés API, Auth de base et schémas d’en-tête personnalisés. Les informations d’identification sont cryptées dans le coffre-fort sécurisé. Pour OAuth 2.0, le moniteur peut actualiser automatiquement les jetons d’accès lorsqu’ils expirent. L’authentification basée sur des certificats (mTLS) est prise en charge pour les points de terminaison gRPC et HTTPS. Les moniteurs SOAP prennent en charge les jetons de nom d’utilisateur WS-Security et les certificats X.509.

Oui. Dotcom-Monitor importe les collections Postman (v2.1) et les exports Insomnia en un clic. Le processus d’importation convertit les requêtes, les en-têtes, l’authentification et les variables d’environnement en moniteurs Dotcom-Monitor. Les flux de travail à étapes multiples sont préservés, et les assertions JSONPath peuvent être ajoutées après l’importation. Les variables comme {{baseUrl}} et {{authToken}} sont automatiquement mappées aux variables Dotcom-Monitor.

Utilisez des assertions JSONPath pour REST et GraphQL (par exemple, $.status == “success” ou $.items.length > 0). Utilisez XPath pour les réponses XML SOAP (par exemple, //OrderStatus/text() = “Confirmed”). Vous pouvez également valider les codes d’état HTTP (200, 201, 204, 400, 500), les en-têtes de réponse (Content-Type, Cache-Control) et les seuils de temps de réponse (par exemple, étape 1 < 500ms, étape 3 < 2000ms). La correspondance de motifs Regex est disponible pour une validation personnalisée.

Lorsqu’un moniteur échoue (erreur de code d’état, échec d’assertion, délai d’attente ou échec de résolution DNS), Dotcom-Monitor envoie des alertes à Slack, PagerDuty, Microsoft Teams, par e-mail ou webhook dans les 30 secondes. L’alerte comprend un diagnostic étape par étape : temps de résolution DNS, durée de la poignée de main SSL, temps de réponse par étape, charges utiles de réponse complètes et messages d’erreur. Les moniteurs réessaient 3 fois avant de déclencher une alerte pour éviter les faux positifs.

Oui. L’Agent Privé de Dotcom-Monitor fonctionne à l’intérieur de votre réseau pour surveiller les API internes, les environnements de staging et les points de terminaison protégés par un pare-feu. L’agent se connecte vers l’extérieur à la plateforme de Dotcom-Monitor (aucune règle de pare-feu entrant requise), exécute les moniteurs selon votre emploi du temps et rapporte les résultats. Les Agents Privés prennent en charge tous les protocoles (REST, SOAP, GraphQL, gRPC, WebSockets, Webhooks) et toutes les méthodes d’authentification.

Dotcom-Monitor fournit une API REST et un fournisseur Terraform pour gérer les moniteurs en tant que code. Vous pouvez créer, mettre à jour ou supprimer des moniteurs depuis des pipelines CI/CD en utilisant des fichiers de configuration YAML. Déclenchez des vérifications API à la demande depuis Jenkins, GitLab CI, GitHub Actions ou CircleCI. Échouez les builds si les temps de réponse API dépassent les seuils ou si les assertions échouent. Exportez les configurations de moniteur vers le contrôle de version pour des pistes d’audit.