Test d’API & chaining request

Article écrit par Ilias Messnaoui

Aujourd’hui nous traiterons d’une fonctionnalité d’outils de test d’API fort pratique.

En effet, j’ai pris l’habitude de vérifier les API de mes amis côté backend afin de pouvoir leur faire des retours rapidement avant de me lancer dans le développement côté frontend. Pour cela j’utilise Postman et Insomnia, car je souhaite identifier leurs points communs et les spécificités de chacun.

Nous découvrirons cette fonctionnalité via le parcours d’un utilisateur qui souhaite se connecter à une application de vente immobilière et consulter ses biens favoris.

Pour les besoins de cet article, j’utiliserai le serveur de mock de Postman afin de simuler l’API de l’application. Insomnia ne propose pas cette fonctionnalité. (Pour les applications frontend, nous utilisons Mirage.js pour les raisons évoquées dans cet article).

Nous aurons donc deux endpoints. Un premier /sign_in pour nous connecter et récupérer les informations d’utilisateurs (notamment le token et l’identifiant du bien).

Puis un second /properties/:id afin de récupérer les caractéristiques des biens. Cette deuxième requête nécessitera une authentification en plus du paramètre.

property_id et token sont des variables vides pour l’instant.

En effet, les deux logiciels nous proposent de créer des variables et de les stocker dans des environnements afin de les utiliser pour des requêtes.

De manière classique, nous devrions faire la requête sign_in dans un premier temps, puis copier les valeurs de la réponse nécessaires dans des variables. Et il faudra le faire à chaque changement de token ou property_id.

{   "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",   "property_id": "c6eccf4a-eac1-4d8b-a650-2ff703a0cd44" } 

Plutôt fastidieux ! Mais ne vous inquiétez pas, le chaining request entre en jeu.

En quoi consiste le chaining request ?

Il s’agit de récupérer les données d’une requête afin de les utiliser dans d’autres requêtes. Typiquement, nous voudrions conserver des valeurs comme les tokens et des identifiants lors de la connexion.

Postman et Insomnia nous propose tous les deux cette fonctionnalité mais de manière différente.

Insomnia, simple et rapide grâce aux templates tags

Les templates tags sont des fonctions qui retournent une valeur finale. Ainsi, elles nous permettent plusieurs choses :

• Génération d’UUID ;
• Possibilité d’encoder et de décoder des variables ;
• Récupérer l’heure actuelle.

Nous pourrions les qualifier de variables dynamiques. Par conséquent, elles sont utilisables aux mêmes endroits que les variables avec la combinaison Ctrl + Espace.

Vous pouvez créer également vos propres templates tags via les plugins d’Insomnia.

Dans notre cas, c’est la fonction response qui nous intéresse. Nous voulons créer des variables à partir de la réponse d’une requête.

Plusieurs paramètres sont à notre disposition :

• Attribute nous permettra de définir ce que nous voulons récupérer de la réponse.
• Request où l’on sélectionnera la requête désirée.
• Filter isolera la donnée souhaitée. Le signe « $ » correspondant au corps entier de la réponse, nous nous aiderons du live preview afin de définir le path du filtre.
• Enfin, Trigger Behavior précisera pour quelle condition renvoyer la requête. Ainsi nous pourrons rafraîchir notre token s’il a une durée de vie de trente minutes. .

Et voici ! Notre variable token est prête. Maintenant, chaque requête utilisant cette donnée lancera si besoin une requête préliminaire.

Je n’ai plus qu’à faire la même chose pour property_id, et notre requête /properties/:id sera « liée » à /sign_in grâce au chaining request

Postman, plus puissant pour une API plus volumineuse.

les scripts dans Postman

Postman embarque un environnement d’exécution basé sur Node.js nous permettant d’utiliser du JavaScript. De plus, nous avons accès à la bibliothèque pm de Postman qui propose de nombreuses fonctionnalités (chaining request, tests).

Nous pouvons exécuter des scripts pour une requête à plusieurs moments :

• Avant la requête grâce à Pre-request Script.
• Après la requête via les Tests.

Dans notre cas, nous souhaitons exécuter un script à la fin de la requête /sign_in (ce sont donc les Tests qui nous intéressent). L’idée, c’est d’utiliser la bibliothèque pm afin de créer des variables à partir de la réponse de la requête.

// Ici l'objet pm.response.json() // retourne le corps de la réponse. const {token, properties} = pm.response.json();  // Il ne reste plus qu'à configurer les variables. pm.environment.set("token", token); pm.environment.set("property_id", properties[0].id); 

pm.environnement se réfère à l’environnement actif de la requête. Nous aurions pu utiliser pm.globals pour des variables globales ou pm.collectionVariables pour des variables de collection.

Sachez qu’il est possible d’ajouter des scripts à des collections également.

Qu’est-ce qu’une collection ?

C’est un conteneur de requêtes disposant de certains outils qu’il partagera avec toutes ces dernières. Les collections sont parfaites pour définir des workflows ou flux d’utilisation.

Dans cet exemple j’ai deux collections. L’une représentant le flux d’un administrateur, l’autre celui d’un utilisateur.

Nous pouvons choisir ainsi, un type d’authentification, des scripts et des variables communs à l’ensemble de la collection.

Enfin nous pourrons lancer la collection afin de tester l’ensemble des requêtes.

Nous retrouvons ici le récapitulatif des tests, mais aussi le résultat des requêtes.

Finalement, les deux requêtes se retrouvent liées par la combinaison des scripts et des collections.

Maintenant, les requêtes en chaîne n’auront pour limite que votre besoin (ou votre imagination) !

En conclusion

Le chaining request s’avère très pratique dans des cas simples. Mais également indispensable pour vérifier des flux d’utilisations ou pour tester des API volumineuses.

La fonctionnalité est commune à Postman et Insomnia. L’utilisation de l’un ou de l’autre sera régie par vos besoins.