# 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: ```bash 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: ```json { "access_token": "abc123" } ``` Then manually: ```http 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: ```text {{token}} {{base_url}} {{user_id}} ``` These variables can be used inside: * URLs * Headers * Auth fields * Request bodies Example: ```text Authorization: Bearer {{token}} ``` Or: ```text {{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: ```text 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: ```text token = $.access_token ``` 3. Use it in the next request: ```text 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: ```text 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.