Steve Fenton

Easy API testing with REST Client extension for Visual Studio Code

Visual Studio Code is becoming my go-to tool for automating stuff. It’s lightweight, it’s a joy to use, and it seems to be able to do pretty much everything ever thanks to a vibrant plugin marketplace. If you test APIs, you might be using an API testing tool of some kind, such as Postman. With Visual Studio Code, though, you can do some really nice API testing with simple text files using the REST Client extension.

Once you install the REST Client Extension, you just open a file (you can call it sample.http) and type a simple request:


The extension will add a “Send Request” option above the request. When you click this, it will send the request and show you the response in another editor pane.

VSCode REST Client

This is super-simple. The file is readable and can easily be shared with your team. You can also save the full response, or the response body into a file.

More complex example

Let’s look at a more complex example so we can see variables, extracting variables from the response, and chained requests.

Variables can be declared using @variable = value. You can define these and re-use them throughout your file.

You can also pull values from the responses to store in a variable, as long as you name the request. You name the request using the special comment # @name = myrequest before the request. You can then use this name to read back values, for example @token = {{myrequest.response.body.access_token}}.

Finally, you can chain requests by separating them with ###.

Let’s put it all together in order to get an auth token from an API and use it to query some values.

@user = SuperTed
@password = SecretMagicWord
@pageSize = 10

# @name login
content-type: application/x-www-form-urlencoded
Authorization: Basic apiuser:apipassword


@token = {{login.response.body.access_token}}


GET{{pageSize}}&page=1 HTTP/1.1
Authorization: Bearer {{token}}

We start off creating some variables for the values that will change frequently. That way they are at the top of the file and we won’t accidentally ruin a request with a bad edit.

Then we name our login request, using # @name login.

We make our POST to the login API, padding content-type and authorization headers. The body of the request follows (and should match the content type you said you would give).

Then we pull the access token out of the response and store it in a variable.

The ### separates our requests, then we make the next request using the token we kept hold of. The UI will underline this when you haven’t yet obtained an access token to remind you to get it first.


The best thing about the REST Client extension is that you can easily see all of the request configuration and you can share it (without the sensitive parts) easily with your team, for example via source control.

Go and grab the extension from the marketplace.

Written by Steve Fenton on