Crédits d’API

Les crédits d’API sont utilisés par les moniteurs d’API multi-étapes et les moniteurs API Postman pour tester les endpoints d’API qui nécessitent plusieurs séquences de requêtes HTTP.

Crédits d’API

Les crédits d’API sont calculés d’après le nombre de requêtes HTTP qu’un moniteur envoie à un serveur web ou à un endpoint d’API. Une requête HTTP est effectuée lorsqu’un client reçoit ou envoie des données, comme lors du chargement du page HTML, de la création d’une nouvelle ressource ou de la mise à jour d’une entrée dans une base de données. Chaque moniteur d’API que vous créez et activez (en mode de production ou de simulation) contient une ou plusieurs requêtes HTTP.

Pour les moniteurs d’API multi-étapes, chaque étape de la requête consomme un crédit. Les étapes d’attente sont gratuites et ne consomment pas de crédit. Pour les moniteurs API Postman, chaque requête dans votre collection consomme un crédit.

Calcul : 1 crédit = 1 requête HTTP = 1 étape dans le moniteur

À la différence des moniteurs de disponibilité et de navigateur, le nombre de moniteurs d’API créés n’a aucune incidence sur les crédits utilisés. Les crédits dépendent du nombre d’étapes d’API, et non pas du nombre de moniteurs. Les intervalles de vérification n’ont pas non plus d’incidence sur les crédits utilisés.

Exemples avec le moniteur d’API multi-étapes

Authentification de base

Imaginons que vous vouliez surveiller le bon fonctionnement de votre authentification de bout en bout. Vous disposez de deux endpoints d’API qui permettent aux utilisateurs de demander un token d’identification et de vérifier sa validité :

• POST /requestToken : endpoint permettant d’obtenir le token. Les utilisateurs doivent généralement fournir leur nom d’utilisateur et leur mot de passe pour demander un token.
• GET /validateToken : endpoint permettant de valider le token.

Dans ce cas, vous devez créer un moniteur d’API qui applique le processus de façon séquentielle. Pour cela, suivez les étapes suivantes :

• Étape 1 : /requestToken
• Étape 2 :/validateToken

Dans ce scénario, vous consommez deux crédits d’API car le moniteur effectue deux requêtes : une pour envoyer l’information (les identifiants) nécessaire pour récupérer le token, et une pour demander la vérification de ce token.

Workflow d’API complexe pour une solution de commande

Supposons que vous ayez une API contenant un grand nombre d’adresses de livraison pour une entreprise de transport. Votre équipe de service à la clientèle reçoit toujours de nombreux tickets demandant des mises à jour de l’adresse de livraison. Pour vous assurer que ce processus fonctionne comme attendu en backend, vous devez surveiller ce workflow.

Vous devez créer un moniteur qui inclut plusieurs endpoints :

• GET /allOrders
• Étape d’attente
• GET /allOrders/{orderId}
• PATCH /allOrders/{orderId}

Dans ce scénario, vous consommez trois crédits d’API car le moniteur envoie des requêtes HTTP aux endpoints GET et PATCH. L’étape d’attente ne consomme pas de crédits, car elle n’envoie pas de requête au serveur et ajoute seulement un délai entre deux requêtes.

Workflow d’API complexe utilisant plusieurs endpoints

Imaginons que vous vouliez surveiller deux workflows d’API différents, par exemple un système de commande et un système de paiement. Vous avez créé deux moniteurs MSA selon la séquence suivante :

• Moniteur A : système de commande. Ce workflow contient trois étapes de requête pour vérifier les informations de commande et modifier un détail de la commande.

  a. GET /allOrders

  b. GET /allOrders/{orderId}

  c. PUT /allOrders/{orderId}

• Moniteur B : traitement du paiement. Ce workflow contient quatre étapes de requête pour vérifier le paiement.

  a. POST /api/authentication

  b. POST /api/payment/validation

  c. Étape d’attente

  d. POST /api/payment/process

  e. Étape d’attente

  f. GET /api/payment/status

Dans ce scénario, le moniteur A consomme trois crédits et le moniteur B en consomme quatre. Chaque étape de requête correspond à un crédit. (3 + 4 = 7 requêtes HTTP)

Exemples avec le moniteur API Postman

Monitoring d’une plateforme d’e-commerce

Imaginons que vous vouliez vérifier le bon fonctionnement du système de paiement de votre plateforme d’e-commerce. Vous avez exporté votre collection Postman et vous l’avez chargée dans Uptrends. Uptrends détecte les requêtes suivantes :

• GET /allOrders
• GET /allOrders/{orderId}
• PUT /allOrders/{orderId}

Ce scénario représente un total de trois crédits. Chaque requête compte comme un crédit.

Traitement de données

Imaginons que vous souhaitiez surveiller votre flux de données et votre pipeline CI/CD de bout en bout. Vous voulez établir une connexion à une source de données, récupérer ces données, transformer les données brutes en un format exploitable pour l’analyse ou la génération de rapports, puis les enregistrer dans votre base de données.

Vous avez utilisé une URL d’API pour votre collection Postman. Uptrends détecte les requêtes suivantes :

• POST /api/v1/datasources/connect
• GET /api/v1/datasources/{connectionId}/fetch
• PATCH /api/v1/pipelines/{pipelineId}/transform
• PUT /api/v1/pipelines/{pipelineId}/save

Ce scénario représente un total de quatre crédits. Chaque requête compte comme un crédit.