L’outil indispensable lorsqu’on développe une API est Postman. Rapidement après avoir fait vos premières requêtes, vous allez devoir récupérer des données, que vous aurez saisies ou qui vous seront retournées par le serveur afin de les réutiliser dans des futures requêtes. Pour cela, les variables Postman vont considérablement vous simplifier la vie. Vous allez pouvoir stocker les ids, les tokens, les clés API dans des variables afin de pouvoir dérouler vos appels les uns après les autres sans avoir à vous interrompre pour copier/coller.
Les variables postman sont divisées en plusieurs scopes:
Les variables globales
Ces variables sont accessibles par tous les environnements et toutes les collections. Elles sont utilisées dans les cas où des variables vont être réutilisées dans plusieurs endroits à travers l’espace de travail sans dépendre de la collection ou de l’environnement.
Pour définir une variable globale:
Lorsqu’il s’agit de variables, il y a toujours des différences suivant l’environnement sur lequel on veut faire des requêtes. Une clé API ne sera jamais la même sur un environnement de dev, de pré-production ou de production.
C’est pourquoi Postman permet de définir des environnements différents pour une même suite de collections. Ainsi, vous pourrez mettre en variable l’URL de façon à faire des appels sur localhost:8080
lorsque vous êtes en cours de développement et, en un clic, changer d’environnement pour faire vos appels sur votre serveur de pré-production ou de production.
Pour définir une variable d’environnement:
Puis si on change d’environnement:
Les variables de session
Certaines variables sont privées et même si vous êtes amené à partager votre collection, vous ne souhaitez pas forcément partager toutes vos variables d’environnement. Par exemple, votre API Key peut être privée et vous ne voulez pas forcément la partager.
Pour çà, il faut modifier la colonne Initial Value
dans la liste des variables d’environnement pour mettre un exemple à la place de la vraie variable.
Dans le développement de votre API, vous allez arriver à un stade où certaines variables seront définies dynamiquement. Par exemple, si vous voulez modifier un objet après l’avoir créé, vous devrez récupérer son ID pour le passer à la requête suivante.
Dans l’exemple ci-dessous, j’ai créé une collection où je crée un objet, je le modifie puis je le supprime:
Je vais avoir besoin de récupérer l’ID retourné par la requête POST pour le passer dynamiquement aux requêtes suivantes.
Étant donné que la variable ID est la même, quel que soit l’environnement et qu’elle pourrait être partagée, je vais la définir directement dans une variable globale à l’issue de la requête.
Pour ce faire, il faut se rendre dans l’onglet Tests
, parser la réponse en JSON et définir la variable globale:
Avant de lancer cette requête, la variable object_id
n’existe pas. Après l’avoir exécuté, on voit dans la liste des variables globales qu’elle est maintenant définie et prête à être utilisée dans les autres requêtes:
Je peux maintenant exécuter toute la collection en effectuant des tests automatisés à chaque requête pour m’assurer que chaque étape se comporte comme désiré.
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…
Dans cette vidéo, on interview Nicolas Grekas, contributeur clé de Symfony, pour discuter de sa…
Comment trouver son job dans la tech ? Marie a la réponse ! Grâce à…
Adobe, l'empire créatif, et pas des moindres ! Belle ascension de la part de ces…
Est-ce plus simple de créer des morceaux avec les outils de Musique Assistée par Ordinateur…