Feature Request: Import variables from another file

Background

When we develop and test some projects, we need to perform certain HTTP requests which are restricted behind authentication, where a token should be included as a header or a search parameter. Also, different testers in a project may have their respective accounts, where each one has its distinguished username and token.

Comparison of Existing Possible Solutions

Solution 1: Use a .env file

It can help, but there is a compatibility problem.

Other implementations in other editors may or may not support the syntax to cite dotenv variables.

Generally, importing variables as plain variables should be compatible enough.

Solution 2: Extension-wide variables

This would require the .http file to cite the variable with a unique name, where the name of a variable must not collide with the variables in other projects which coexist with the current project on the same machine.

However, sometimes we need to work with some similarly structured projects, which honor the same convention on variable naming, resulting in reusing the same variable name across projects. This case is especially prominent for enterprise IT solution providers (teams and freelancers).

Major Concerns

Our major concerns are listed as:

• Reuse local variable syntax;
• Avoid duplicate definitions across multiple .http files;
• Stay compatible with existing declarations, if possible.

Proposed Solution

Declaring Variables

The variables are defined in .env like before. There shall be no difference for people who already practice Solution 1.

Alternatively, the user may choose to use a different file; but the syntax in the file stays compatible with the .env file.

Using Variables

In a .http file, the user may write a line:

from .env import authToken

… to import the authToken variable. After imported, a request can cite authToken variable with {{authToken}}; the syntax is same to citing a locally defined variable.

Also, the user may write a line:

from .env import { authToken, username, hostAndPort}

… to import 3 variables in 1 line.

Therefore, the user may write a request like:

GET http://{{hostAndPort}}/api/userProfile/{{username}}
Bearer: {{username}}:{{authToken}}

If the user chooses to use a different file, the .env substring in the examples above shall be replaced with the actual filename.

[Sebaestschjin]

Is it also possible to “store” a variable into the environment?

My usecase is, that I have different types of login requests for the API. All result in a OAuth Bearer Token. The actual API calls then use that token and may retrieve different results depending on which login call was used.

I’d like to have one file per API resource and separate the login requests into different files. My goal would be, to store the result of a login request into a variable and simply use that in the header of the others request. Otherwise I’d have to duplicate the login calls into all API resource files, which is quite nasty.

[adibradfield]

Currently, you can store variables under the vscode setting rest-client.environment Variables and access them as standard variables. Because this is a vscode setting, you can set values for your user, machine, or the workspace. Just go to the preferences in vscode and search for rest-client.environmentVariables. You will need to manually enter your variables as a json dictioonary into the settings file.

This means that you can put variables that you want to share between projects in either your user or machine settings, and then any project specific variables can go in your workspace settings.

As well as having the 3 places you can put these variables, you can also have different environments like this (the $shared environment gets shared between all environments):

{      
    "rest-client.environmentVariables": {

        "$shared": {
          "timeout": "60000"
        },
        "development": {
          "url": "dev.example.com"
        },
        "staging": {
          "url": "stage.example.com"
        },
        "production": {
          "url": "example.com"
        }
      }
}

You can then switch environments by opening the command pallete and running the REST Client: Switch Environment command

Does this feature solve your problem?