• 6 Posts
  • 12 Comments
Joined 21 days ago
cake
Cake day: February 22nd, 2026

help-circle
  • Hey, that’s a fair comparison. .http files are actually one of the closest things conceptually.

    The difference is mostly in how far the idea is pushed.

    .http files are basically request definitions written in HTTP syntax. They are great for sending requests and keeping them next to your code.

    Voiden treats the Markdown file more like an executable API workspace. Requests are composed from reusable blocks (endpoints, auth, headers, params, bodies, etc.), so instead of copying similar requests around you can structure them like small building blocks and reuse them across the file. That becomes useful once an API grows and you start repeating the same pieces everywhere.

    Another difference is that the file can mix documentation, explanation, requests, tests, and scripts in the same place and actually run them. The goal is that the file itself becomes the living artifact of the API workflow rather than just a request list. And since everything is still plain text and Git-friendly, you can keep it alongside the codebase the same way you would with .http.

    If someone is happy with .http files they probably don’t need Voiden. The idea is more for teams that want the requests, tests, and docs to live together in one executable spec rather than spread across tools.

    Do you use .http mostly for quick testing, or do you keep full API workflows in them?









  • Curl is great. I use curl. Most developers use curl. But “you can call an API with curl” and “curl is enough as an API working environment” are two very different claims.

    The problem is that real API work is almost never just one request typed into a terminal like some kind of beautifully minimalist Unix haiku. It usually turns into auth, environments, copied headers, reused payload fragments, request chains, documentation, testing, debugging, sharing examples with teammates, reviewing changes in Git, and trying not to break prod because you forgot to swap one token or one base URL.

    At that point, people are not really using “just curl” anymore. They are using curl plus shell scripts, plus notes, plus env files, plus copied commands from Slack, plus random JSON files, plus tribal knowledge. Which is fine, until it becomes annoying, fragile, and weirdly hard to collaborate around.




  • curl is great. I use curl. Most developers use curl. But “you can call an API with curl” and “curl is enough as an API working environment” are two very different claims.

    The problem is that real API work is almost never just one request typed into a terminal like some kind of beautifully minimalist Unix haiku. It usually turns into auth, environments, copied headers, reused payload fragments, request chains, documentation, testing, debugging, sharing examples with teammates, reviewing changes in Git, and trying not to break prod because you forgot to swap one token or one base URL.

    At that point, people are not really using “just curl” anymore. They are using curl plus shell scripts, plus notes, plus env files, plus copied commands from Slack, plus random JSON files, plus tribal knowledge. Which is fine, until it becomes annoying, fragile, and weirdly hard to collaborate around.

    That is the gap Voiden is trying to solve.

    So for me it is not “curl vs Voiden.” curl is a low-level execution tool. Voiden is a workspace for actual API work: writing requests, organizing them, reusing pieces, documenting them, testing them, versioning them in Git, and not duplicating the same headers/body/auth setup 45 times like a person slowly losing control of their life.