Feature Request: Import variables from another file

[neruthes]

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.

[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?

[donile]

Is it possible to compose a variable from multiple environment variables and re-use that variable throughout .http files? For example:

{
    "rest-client.environmentVariables": {
        "$shared":
        {
        },
        "local": 
        {
            "protocol": "https",
            "hostname": "localhost",
            "port": "5001",
            "routing-segment": "/"
        },
        "development": 
        {
            "protocol": "https",
            "hostname": "dev.host.com",
            "port": "443",
            "routing-segment": "/options",
        }
    }
}

And then create a variable, base-url: {{protocol}}://{{hostname}}:{{port}}{{routing-segment}} once that is shared throughout the .http files?

[oshliaer]

@adibradfield, yep, it's fine. But I didn't see this in the docs. Is there a link to an article about this?

[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.

[ThenTech]

(also see #943)

The ability to refer to variables defined in other .http files would be ideal to share auth tokens that were extracted from a previous request. Exactly as @Sebaestschjin mentions, I also see the use-case of having one file that performs the login and then other files dedicated to each API resource that can use the Bearer Token from the login.http file.

Currently, the only way to do this, is to either do the login request and copy the token to the global .vscode settings, or copy the login request to every other .http file and perform it again in each file when needed.

[Sebaestschjin]

(also see #943)

The ability to refer to variables defined in other .http files would be ideal to share auth tokens that were extracted from a previous request. Exactly as @Sebaestschjin mentions, I also see the use-case of having one file that performs the login and then other files dedicated to each API resource that can use the Bearer Token from the login.http file.

Currently, the only way to do this, is to either do the login request and copy the token to the global .vscode settings, or copy the login request to every other .http file and perform it again in each file when needed.

I started switching to this tool instead: https://github.com/AnWeber/vscode-httpyac which is similar in how this one works and has even more features. Sharing variables between scripts is on of them. :-) It also has an easy to use plugin mechanisms which I now use to set the required API access tokens for requests.

[ThenTech]

I started switching to this tool instead: https://github.com/AnWeber/vscode-httpyac which is similar in how this one works and has even more features. Sharing variables between scripts is on of them. :-) It also has an easy to use plugin mechanisms which I now use to set the required API access tokens for requests.

I think I am going to set-up Thunder Client instead, since it's easier there to have it perform the login automatically before requests are done and save the token to the environment automatically.

[pocomane]

I also would prefer simply loading other .http/.rest files. I am evaluating httpyac alternative too, but currently it seems an overkill for me. Moreover, a .http/.rest import statement would play better with revision control (actually .env files in revision control are strongly discouraged).

[AnWeber]

@pocomane why do you feel it is a overkill? Importing is only using @import ./var.http are the docs to overwhelming. How can httpyac improve?

[pocomane]

@AnWeber I may be wrong, but httpyac seems me to have a lot more feature (e.g. script) than Rest Client. I do not need them... I just want a simple way to make http requests.

[neruthes]

Hello everyone. Thank you all for your interest in this topic. I feel very encouraged and inspired, and many ideas gave me new ways to look into the matter.

I have not been using this software for a while, so I would like to stay away from the discussions here.

However, I think that I am not at liberty to close this issue, since many great inputs may remain to be address by future development. Therefore, I will be unsubscribing from this issue and will leave the decision of whether it should be closed to the maintainers of this repository.

And I look forward to seeing the day when new projects bring this software back to my work, and I will be happy to offer new inputs on this issue if it still requires any.

[serverlesspolska]

I will chip in.

I have a dotfile under different name .<something>env in different folder.

I wish REST Client would expend current functionality

{{$dotenv [%]variableName}}: Returns the environment value stored in the .env file which exists in the same directory of your .http file.

To support more configurable setup like {{$dotenv filePath/fileName[%]variableName}}