Building qurli — A Lightweight Terminal-Native HTTP Client for Developers

As a DevOps engineer, I spend a lot of time working with APIs directly from the terminal.

Most of the time, the workflow looks something like this:

curl -X POST ...

Then:

• modify headers

• change auth tokens

• resend requests

• copy tokens from one response into another request

• pretty-print JSON manually

• repeat the same workflow again and again

GUI tools like Postman and Insomnia solve many of these problems, but they also come with their own overhead:

• heavy desktop apps

• high memory usage

• workspace complexity

• cloud sync

• account systems

• unnecessary UI clutter

And in many real-world debugging situations, installing a GUI API client is not even an option.

When I’m connected to a remote Linux server over SSH and need to quickly test an internal API, curl is usually the only practical choice. That works, but once headers, auth, JSON bodies, and chained requests enter the picture, the command becomes harder to manage.

I wanted something simpler.

Something that:

• starts instantly

• works over SSH

• feels native in the terminal

• stays keyboard-driven

• keeps the power of curl

• removes repetitive friction

That’s why I started building qurli.

---

What is qurli?

qurli is a lightweight terminal-native HTTP client built in Rust.

Think of it as:

curl, but with a TUI.

The goal is not to replace Postman entirely.

The goal is to make day-to-day API workflows faster for terminal-first developers, especially in environments where opening a GUI tool is inconvenient or impossible.

---

Why Rust?

This project felt like a perfect fit for Rust because I wanted:

• fast startup

• low memory usage

• single binary distribution

• smooth terminal rendering

• good async support

• cross-platform support

The stack currently uses:

• ratatui

• crossterm

• reqwest

• tokio

• serde

---

The Pain Point That Pushed Me to Build This

One thing I repeatedly face while testing APIs is authentication flow handling.

A very common workflow looks like this:

1. Send a login request

2. Copy the token from the response

3. Paste that token into the next request

4. Repeat whenever the token changes

Example response:

{
  "access_token": "abc123"
}

Then manually:

Authorization: Bearer abc123

This becomes annoying very quickly.

So in qurli v1.1.0, I added runtime variables and JSON extraction rules to make chained requests much easier.

---

Runtime Variables

You can now define reusable variables like:

{{token}}
{{base_url}}
{{user_id}}

These variables can be used inside:

• URLs

• Headers

• Auth fields

• Request bodies

Example:

Authorization: Bearer {{token}}

Or:

{{base_url}}/api/users/{{user_id}}

This keeps requests cleaner and avoids repeatedly editing the same values by hand.

---

JSON Extraction Rules

qurli can automatically extract values from JSON responses and store them as variables.

Example:

token = $.access_token
user_id = $.user.id
first_item = $.items[0].id

So after a login request succeeds, the token can automatically become available for future requests.

A typical flow now looks like this:

1. Send a login request

2. Extract the token with:

   token = $.access_token
   

3. Use it in the next request:

   Authorization: Bearer {{token}}
   

No manual copying. No switching tools. Just a smoother terminal workflow.

---

Secret-Aware Handling

Since tokens and credentials are sensitive, I also added safeguards around them.

qurli now supports:

• secret-aware masking for token/password/API key style variables

• safer curl previews with masked secrets

• improved history redaction

The goal is to keep the terminal workflow practical without accidentally leaking sensitive values on screen or into stored history.

---

What qurli Can Do Today

The project is still evolving, but the foundation is already useful.

Current capabilities include:

• interactive terminal UI

• URL, method, header, auth, and body editing

• request execution

• response viewer

• pretty-printed JSON output

• generated curl preview

• runtime variables

• JSON extraction rules

• chained request workflows

• request history

• secret-aware masking

I’ve also added automated tests covering:

• curl generation

• header parsing

• auth handling

• variable substitution

• extraction rules

• JSON formatting

• history handling

---

Why I’m Keeping It Minimal

One thing I want to avoid is turning qurli into another giant API platform.

I do not want:

• cloud sync

• accounts

• telemetry

• AI features everywhere

• complex workspace systems

• heavy abstractions

I want it to remain:

• lightweight

• portable

• keyboard-first

• terminal-native

That simplicity is the whole point.

---

What’s Next?

Some features I’m considering for future releases:

• WebSocket support

• multipart uploads

• OpenAPI import

• response diffing

• environment profiles

The challenge will be adding useful workflows without losing the minimal feel of the tool.

---

Try qurli

The project is open source and available on GitHub:

https://github.com/crypticani/qurli

If you’re someone who lives in:

• Linux

• terminals

• SSH sessions

• DevOps workflows

• backend debugging

then qurli might be useful for you too.

---

Final Thoughts

This project started because I wanted a smoother API workflow inside the terminal without depending on heavyweight GUI tools.

curl is excellent, and I still use it all the time. But for interactive API debugging, especially on servers or in multi-step flows, I wanted something a bit more ergonomic without leaving the terminal.

That idea became qurli.

Feedback, ideas, and contributions are welcome.