Variables et environnements

Les variables de Restorm vivent dans un dossier de variables, qui peut en contenir plusieurs jeux : un par environnement.

Environnements et sous-environnements

Un environnement est une liste de couples clé / valeur. Il peut contenir des sous-environnements, qui héritent de leur parent et surchargent ce qu’ils redéfinissent.

C’est le bon outil pour modéliser recette → recette / client A, recette / client B : la base commune est écrite une fois, seule la différence est répétée.

Choisir l’environnement actif

Le sélecteur d’environnement est à gauche de la smartbar de chaque onglet de requête. Il affiche une pastille colorée et le nom de l’environnement.

Le popover propose une case « Appliquer à toutes les requêtes » : cochée, elle bascule tout le dossier d’un coup — c’est ce que vous voulez pour passer l’ensemble d’un projet de local à recette.

Types de valeurs

Une variable n’est pas qu’une chaîne. Restorm typiquement propose :

Type	Ce que c’est
Chaîne	Une valeur littérale, envoyée telle quelle
Expression	Un gabarit Handlebars — c’est le seul type dont les {{ }} sont évalués
Numérique	Un nombre, avec un format d’affichage
Booléen	Vrai / faux
Date-heure	Une date ISO, avec un format
Couleur	Une couleur hexadécimale
Secret	Une référence vers une source de secret — la valeur ne transite jamais dans le fichier projet
Liste	Une liste de valeurs
Énumération / Énumération multiple	Une valeur contrainte par une énumération importée
Liste personnalisée / Liste personnalisée multiple	Un choix par libellé dans une liste de valeurs personnalisée
Variable	Une référence vers une autre variable
Environnement	Une référence vers un environnement
Nul	La valeur nulle explicite

Chaîne ou expression ?

C’est le piège numéro un. Une variable de type Chaîne qui contient Bearer {{token}} sera envoyée littéralement, accolades comprises. Pour que la substitution ait lieu, la valeur doit être de type Expression.

Ordre de résolution

Du plus général au plus spécifique — le dernier gagne :

1. l’environnement racine, puis chaque sous-environnement de la chaîne ;
2. les variables de l’environnement lui-même, dans leur ordre de déclaration : une variable peut donc s’appuyer sur celles définies au-dessus d’elle ;
3. les variables de run posées par un scénario (action Définir variable), qui recouvrent l’environnement le temps de l’exécution ;
4. les valeurs propres à la requête (en-têtes, paramètres de requête, paramètres de chemin), chaque groupe se résolvant sur le contexte accumulé ;
5. enfin les {{ }} écrits directement dans les champs de la requête — voir Variables en ligne.

Restorm fait par ailleurs plusieurs passes : une expression d’un environnement parent peut donc récupérer une valeur redéfinie par un enfant.

Variables désactivées

Chaque variable a une case d’activation. Une variable désactivée n’entre pas dans le contexte — c’est le moyen propre de neutraliser temporairement une surcharge sans la supprimer.

À l’import, les couples clé / valeur dont la valeur se résout à vide sont automatiquement désactivés : votre première exécution n’envoie donc pas une nuée d’en-têtes vides.

Et les helpers ?

Toute expression est un gabarit Handlebars, avec plus de cent helpers disponibles : chaînes, maths, dates, listes, encodage, hachage, données aléatoires.

Une variable l’emporte sur un helper

Si vous avez une variable nommée min et qu’il existe aussi un helper min, {{min}} (sans argument) lit la variable, et {{min a b}} (avec des arguments) appelle le helper.