JetBrains IDEs include an HTTP Client that creates, edits, and executes requests directly in the
code editor. Requests live in .http files, so they can sit beside application code and travel
through Git instead of living only in an application database.
JetBrains has grown a powerful language around that foundation—scripts, dynamic variables, GraphQL, gRPC, WebSocket, response handlers, and a CLI. Start with the portable core before deciding which of those tool-specific features a project actually needs.
Send a request from the editor
Create api.http and add a request:
GET https://jsonplaceholder.typicode.com/todos/1
Accept: application/json
Use the run icon beside the request. If the file contains multiple blocks, separate them with
### and run the block you need.
@baseUrl = https://jsonplaceholder.typicode.com
GET {{baseUrl}}/todos/1
###
POST {{baseUrl}}/posts
Content-Type: application/json
{
"title": "Created from an .http file",
"userId": 1
}
That example also runs in clients that support the common .http conventions, including Karve.
Public and private JetBrains environments
JetBrains uses http-client.env.json for shareable values and
http-client.private.env.json for secrets. A selected environment might provide host, username,
and token values to {{host}} references in a request.
JetBrains notes that its IDE Git integration does not track the private file, but a terminal or a
different Git client may still see it unless the path is explicitly ignored. Add the private file
to .gitignore; do not depend on one IDE integration as the security boundary.
Karve deliberately uses dotenv files instead:
baseUrl=https://api.example.com
token=replace-locally
The request stays simple:
GET {{baseUrl}}/me
Authorization: Bearer {{token}}
The environment container is different, but the request text remains portable.
Know where portability stops
These elements form a useful shared subset:
- uppercase HTTP method and URL
- normal headers and request body
###separators- comments
- file variables declared with
@name {{name}}references
JetBrains-specific features include pre-request and response-handler scripts, JSONPath variable semantics, dynamic variables such as generated UUIDs, protocol support beyond REST, run/debug configurations, and its HTTP Client CLI. Karve is REST-only and does not execute those scripts.
Keeping this boundary visible prevents the familiar failure where a file appears standardized but quietly depends on one IDE's runtime.
Organize files for several services
Put request files near the service that owns them when that helps code review:
services/
catalog/
requests/catalog.http
orders/
requests/orders.http
JetBrains works naturally inside each project. Karve can gather both files into virtual folders without moving them, which is useful when debugging a workflow that crosses repositories. Changes still land in the original files and appear in the correct Git diff.
When to use each tool
Use JetBrains HTTP Client when advanced scripts, protocol support, run configurations, or the CLI
are part of the workflow. Use Karve when the job is focused REST work on Windows and you want a
dedicated native workspace, .env selection, structured responses, and persistent searchable
history around otherwise plain request files.
Neither choice requires converting the portable requests. Tool-specific blocks may still need a simpler Karve-compatible version.
Weighing the IDE client against a dedicated app? The Karve vs JetBrains HTTP Client comparison covers the product side of that decision.
Primary references
- JetBrains Help: HTTP Client in the code editor
- JetBrains Help: HTTP Client variables
- JetBrains Help: HTTP Client CLI