VS Code as a REST Client

API Testing & Tooling — VS Code as a REST Client
API Testing & Tooling
Chapter 5 · VS Code as a REST Client

📝 VS Code as a REST Client

Chapter 1 named "requests that need to live in version control, reviewable in a pull request" as a case Postman doesn't fit well. This chapter delivers on that directly: the REST Client extension turns API requests into plain-text files that sit in the same Git repository as the code that calls them.

Why a Plain-Text Request File?

A Postman collection lives inside Postman's own application state (or a separately exported JSON file). An .http file is just a text file — it sits in the repo, shows up in git diff, gets reviewed in a pull request like any other change, and needs no export/import step to stay in sync with the code around it.

The REST Client Extension

After installing the REST Client extension, any file with a .http (or .rest) extension gets a clickable "Send Request" link above each request, right in the editor. The syntax is close to raw HTTP: a method and URL, optional header lines directly below, a required blank line, then an optional body.

GET https://api.example.com/products/42 ### POST https://api.example.com/products Content-Type: application/json { "name": "Wireless Mouse", "price": 24.99 }

### on its own line separates multiple requests within one file — each gets its own "Send Request" link.

Variables in .http Files

Variables use @name = value at the top of the file, referenced later with {{name}} — the same mental model as Postman's environment variables (Chapter 3), just written directly as plain text instead of managed through a UI.

@baseUrl = https://api.example.com GET {{baseUrl}}/products/42

For values that genuinely differ per environment (and especially anything sensitive), the extension also supports a separate http-client.env.json file defining named environments — the .http file itself stays identical across dev/staging/production, referencing whichever environment is currently selected.

Chaining Requests in .http Files

A request can be named with # @name, and a later request can pull a value straight out of its response — the REST Client's equivalent of Chapter 3/4's Postman chaining, expressed as file syntax instead of a click or a script.

# @name login POST {{baseUrl}}/login Content-Type: application/json { "email": "dana@example.com", "password": "..." } ### GET {{baseUrl}}/me Authorization: Bearer {{login.response.body.$.token}}

The second request never runs in isolation — it always uses whatever token the named login request's response actually contained, the moment it was last sent.

Thunder Client: A Postman-Like GUI, Inside VS Code

Thunder Client is a different extension entirely — a full Postman-style GUI (collections, environments, a visual request builder) running directly inside VS Code, for developers who want Postman's visual workflow without leaving the editor or maintaining a separate application.

REST Client (.http Files) vs. Thunder Client

REST Client

Plain text, lives in the repo, reviewable in a diff — closer to "requests as code" than "requests as a GUI collection."

Thunder Client

A visual, Postman-like interface inside VS Code — collections and environments managed through the GUI, not hand-written text.

SyntaxMeaning
###Separates multiple requests in one file
@name = valueDefines a variable
{{name}}References a variable
# @name labelNames a request so its response can be referenced later
{{label.response.body.$.field}}Pulls a field out of a named request's response

💻 Coding Challenges

Challenge 1: Convert a Postman Request to .http

Convert this Postman request into .http file syntax: POST {{baseUrl}}/orders with an Authorization: Bearer {{authToken}} header and a JSON body { "productId": "P200", "quantity": 1 }.

Goal: Practice the exact syntax — method/URL line, header line, required blank line, then body.

→ Solution

Challenge 2: Chain a Named Request

Write a two-request .http file: name the first request createOrder (returns { "id": "O5521" }), then have a second request GET that order's status using the id from the first response.

Goal: Practice the # @name and {{label.response.body.$.field}} chaining syntax on a scenario other than the chapter's login example.

→ Solution

Challenge 3: REST Client or Thunder Client?

A team wants API request definitions reviewed in pull requests, diffable in Git history, with no proprietary export format involved. Which tool fits better, and why does the other one fall short for this specific requirement?

Goal: Practice applying the chapter's REST Client vs. Thunder Client comparison to a concrete team requirement.

→ Solution

⚠️ Gotcha: "Commit Your Requests" Doesn't Mean "Commit Every Value in Them"

The whole appeal of this chapter is that .http files are plain text meant to be committed — but the http-client.env.json file holding real environment values can easily contain the exact same kind of sensitive data a Postman environment export does (Chapter 3's gotcha): a real API key, a production credential. The .http request files themselves — which just reference {{variableName}} — are safe and meant to be committed; the environment file holding the actual values for anything sensitive should be .gitignore'd, exactly like a .env file, even though the whole point of this tool is version control.

🎯 What's Next

The next chapter leaves the editor entirely: cURL Fundamentals — the terminal-native tool that works anywhere a shell does, no GUI or extension required.