VS Code REST Client Guide — Run .http Files

The REST Client extension by Huachao Mao helped make .http files a practical API workflow. It lets you write a request in the VS Code editor, select Send Request, and see the response in a separate pane. The extension also recognizes .rest, supports multiple requests per file, and adds history, environments, authentication helpers, GraphQL, and response-to-variable workflows.

This guide starts with the subset worth keeping portable.

Install the extension and create a file

Install REST Client from the Visual Studio Marketplace. Create api.http inside your repo:

GET https://jsonplaceholder.typicode.com/posts/1
Accept: application/json

Select the CodeLens link above GET, or place the caret in the request and use the extension's send command. The response opens in another editor pane.

The method is optional in the extension—it treats a bare URL as GET—but writing the method makes the file clearer and more compatible with other clients.

Put several requests in one file

Use ### on its own line to separate request blocks:

@baseUrl = https://jsonplaceholder.typicode.com

# @name getPost
GET {{baseUrl}}/posts/1

###

POST {{baseUrl}}/posts
Content-Type: application/json

{
  "title": "A request kept with the code",
  "body": "Plain text is easy to review",
  "userId": 1
}

The file variable and separator are broadly understood. The # @name annotation and advanced response chaining belong to the VS Code REST Client feature set; another client may ignore or reject those additions.

Choose the right variable scope

The extension supports several scopes:

File variables such as @baseUrl live in the current file.
Environment variables live in VS Code settings and can change when you switch environments.
Request variables can extract a value from an earlier named response.
System variables generate or retrieve values through extension-specific syntax.

Prefer an ordinary file variable for a non-secret value used throughout one file. Use an environment for hosts and credentials that differ by machine or deployment. Never commit a real bearer token merely because the request file makes it convenient to paste one.

Karve uses the same {{name}} references with file-level @name values and selected per-file .env environments. It does not implement the extension's response chaining, GraphQL, Digest/Azure/AWS auth helpers, or system-variable language.

Keep files useful outside VS Code

The safest shared core is deliberately small:

Write the HTTP method explicitly and in uppercase.
Keep the URL on the request line.
Use standard Header: value lines.
Put one blank line before the body.
Separate requests with ###.
Use simple @name declarations and {{name}} references.

When a request needs a VS Code-only feature, document that near the block instead of assuming every runner behaves the same way.

When a dedicated client helps

The extension is hard to beat when you already live in VS Code and want zero context switching. Karve solves a different problem: collecting existing .http and .rest files from multiple repos into one native Windows workspace, running them without opening each codebase, and keeping full request/response history searchable across sessions.

There is no migration format. The same files stay on disk and remain editable in VS Code. See the Karve vs VS Code REST Client comparison for the product trade-off rather than the syntax tutorial.

Common problems

No Send Request link: confirm the file language is HTTP and the extension is enabled.
The wrong request runs: place the caret inside the intended ### block.
An environment value is missing: check the active environment shown by the extension.
A portable runner rejects the file: remove named-request, chaining, or system-variable syntax until only the shared core remains.
History contains credentials: treat local history as sensitive and clear it when appropriate.

VS Code REST Client: a practical .http file guide