Variables and environments

Restorm’s variables live in an environment folder, which can hold several sets of them: one per environment.

Environments and sub-environments

An environment is a list of key / value pairs. It can contain sub-environments, which inherit from their parent and override whatever they redefine.

That is the right tool for modelling staging → staging / customer A, staging / customer B: the common base is written once, only the difference is repeated.

Choosing the active environment

The environment picker sits at the left of every request tab’s smartbar. It shows a coloured badge and the environment’s name.

The popover offers an “Apply to all requests” tickbox: when ticked, it switches the whole folder in one go — which is what you want in order to move an entire project from local to staging.

Value types

A variable is more than a string. Restorm offers:

Type	What it is
String	A literal value, sent as it is
Expression	A Handlebars template — the only type whose {{ }} are evaluated
Number	A number, with a display format
Boolean	True / false
Date time	An ISO date, with a format
Color	A hexadecimal colour
Secret	A reference to a secret source — the value never passes through the project file
List	A list of values
Enumeration / Multiple enumeration	A value constrained by an imported enumeration
Custom list / Multiple custom list	A choice by label from a custom value list
Variable	A reference to another variable
Environment	A reference to an environment
Null	The explicit null value

String or expression?

This is trap number one. A String variable containing Bearer {{token}} is sent literally, braces included. For substitution to happen, the value must be of type Expression.

Resolution order

From the most general to the most specific — last one wins:

1. the root environment, then each sub-environment down the chain;
2. the environment’s own variables, in declaration order: a variable can therefore build on the ones defined above it;
3. run variables set by a scenario (Set variable action), which cover the environment for the duration of the run;
4. the request’s own values (headers, query parameters, path parameters), each group resolving against the accumulated context;
5. finally the {{ }} written directly in the request’s fields — see Inline variables.

Restorm also makes several passes: an expression in a parent environment can therefore pick up a value redefined by a child.

Disabled variables

Every variable has an enable tickbox. A disabled variable does not enter the context — that is the clean way to neutralise an override temporarily without deleting it.

At import time, key / value pairs whose value resolves to empty are disabled automatically: your first run therefore does not fire off a swarm of empty headers.

What about helpers?

Every expression is a Handlebars template, with over a hundred available helpers: strings, maths, dates, lists, encoding, hashing, random data.

A variable beats a helper

If you have a variable named min and a min helper also exists, {{min}} (with no argument) reads the variable, and {{min a b}} (with arguments) calls the helper.