The VSCode REST Client extension has made my API testing process pretty straightforward:

1. I keep a dedicated folder of .http files for each project, organized by functionality.
2. When building new features, I create a new .http file or add to an existing one with the relevant endpoints.
3. Using split-pane in VS Code, I code in one panel and test APIs in another without context switching.
4. For different environments, I maintain a simple variables section at the top of each file.

The stability and simplicity keep me using REST Client. There's no account to maintain, no surprise UI revamps, and no forced cloud syncing of my requests.

Plus, everything is just text. When I need to remember how I called that one obscure endpoint six months ago, it's right there in version control, not buried in some cloud-synced collection I can't easily search.

Organizing API Requests

I organize my API requests by service or functionality, creating a clean structure that's easy to navigate:

project/
├── auth/
│   ├── login.http
│   └── refresh.http
├── users/
│   ├── profile.http
│   └── settings.http
└── data/
    └── queries.http

This structure makes it easy to find related endpoints and keeps my testing organized as projects grow.

Variables

I define variables directly within my .http files using a named variables section:

# @name Variables
@dev = https://dev-api.example.com
@prod = https://api.example.com
@defaultModel = llama3.2

These variables can be placed anywhere in the file and referenced in subsequent requests. For sensitive information like API keys, I use $dotenv, to read secrets from my .env file which is not added to version control:

### Auth example
GET {{dev}}/users/me
Authorization: Bearer {{$dotenv API_KEY}}

### Using variables in request bodies
POST {{prod}}/completions
Content-Type: application/json
Authorization: Bearer {{$dotenv API_KEY}}

{
  "model": "{{defaultModel}}",
  "messages": [
    {
      "role": "user",
      "content": "Hello!"
    }
  ]
}

Request Templates

I create template requests that can be quickly duplicated and modified:

### Get user profile
GET {{dev}}/users/profile
Authorization: Bearer {{$dotenv AUTH_TOKEN}}
Content-Type: application/json

For more complex scenarios, I can build on these templates:

### Create new item
POST {{dev}}/items
Authorization: Bearer {{$dotenv AUTH_TOKEN}}
Content-Type: application/json

{
  "name": "Test Item",
  "description": "This is a test item",
  "category": "testing",
  "active": true
}

This workflow lets me iterate quickly while testing APIs, with all my example requests documented right alongside my code.

Get Started

If you want to see practical examples of this workflow, check out my curl-collection repository. It contains a variety of HTTP files for testing different APIs that you can use as a reference.