
US Operational Postman Platform on Desktop ? Operational Postman Platform on Browser ? Operational Postman Login ? Operational </
US Operational
Postman Platform on Desktop ? Operational
Postman Platform on Browser ? Operational
Postman Login ? Operational
Postman Monitors ? Operational
Postman Mocks ? Operational
Postman API ? Operational
Postman API Network (API Explore) ? Operational
Run Button ? Operational
Postman Search ? Operational
Public Collection Documentation ? Operational
Newman ? Operational
Postman Learning Center and Documentation ? Operational
Postman Support and Community Forum ? Operational
Postman Integrations ? Operational
Postman Interceptor Operational
Marketing Website ? Operational
Postbot ? Operational
Postman VS Code extension ? Operational
API Builder ? Operational
API Specifications ? Operational
Collection Runner Operational
Postman CLI Operational
I stopped using Postman when it magically started connecting to a central server for… nothing useful, really. I have no idea why people would design software this way, especially a development tool that should work with any web server, under any network condition (including fully offline against localhost).
Now I just have a Makefile with a bunch of curl invocations, or Python tests with requests to match against expected responses.
We went with a mix of curl, Invoke-WebRequest, favourite scripting language, HTTP files, IDE tooling, Insomina, after Postman went cloud online and became a forbidden tool on our systems.
Also I am not counting that Insomina won't follow the same footsteps as Postman.
I wrote my own api invoker, https://placeholders.cc/api-invoker/, mainly because postman is slow, eats a ton of memory and it becomes more and more restrictive to non logged in users. In don't mind having an electron based application like open. but i hate to have 10 like it open in the same time.
Allow me to introduce you to Hurl: https://hurl.dev/
or you can just use curl :)
>Now I just have a Makefile with a bunch of curl invocations
There are several FOSS command line tools that can do this easier, e.g. https://httpie.io/cli
That syntax just seems slightly more confusing than curl, not easier except for very specific simple requests.
I find it's a more streamlined syntax, and has added-on stuff curl doesn't have to make rest testing easier, e.g. --session
Other than that, sure, mostly similar.
What about Bruno[1]?
+ 1. I just came across it a few months ago after getting fed up with Postman's unintuitive ever-changing UI, etc. So far so good. Easy to store bruno files in a repo to have a nice easy place to go to get test calls
I desperately want to like Bruno, since I think it might not do the same rugpull as Postman and Insomnia.
But the UX is just terrible (for me) or at least has been every time I've tried to start using it more.
I mean, come on, the most basic use of creating a request goes like this:
1. Sorry, can't let you create a request before you create a collection.
2. Sorry, can't let you create a collection before you make a decision on in which path you will be storing all your collections.
3. Sorry, can't let you create a request before you think of a good name for it.
etc.
Like what the heck? This should be just one click to create a new untitled request then fill in the URL and send.
At first I thought this might be growing pains since it was new but every year I try it and it hasn't improved.
+1 also. More than being open source and local, you can import your postman requests. It's almost 1:1.
tried it but had some buggy interface when i used it full-time earlier this year. (albeit i work in a slow vm)
it might have changed now but it did not support grpc endpoints, which was a dealbreaker for me. but definitely appreciate the project and i hope it reaches core feature parity soon.
Hurl (https://hurl.dev/) is quite good
People that want to make money on their software obviously.
Connecting to a license server is pretty much standard.
For Postman it is annoying because it was never explicitly stated and it seemed like they are cool kids making nice helpful app. But really they are in for money. Which is not bad have to say but the way they did it is bad.
I think they started as cool kids and they changed their mind on the way. I'm using postman for a long time. I liked it, i preferred the online version, slowly slowly they started to push users towards the app, making it harder and harder first to use it without and account, then to use the online version. This is how I ended up with a heavy desktop app, when i needed something simple and easy to use.
I switched to k6 the cli load test tool for its full js/ts scripting ability
Pretty obvious why if you use the software.
I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software.
That's who pays for all your tools to have free versions.
People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying to use aren't worth any money to companies.
My experience is the opposite.
Teams that are knowledgeable jury rig their own custom solutions without all the enterprise cruft. They make solutions that fix their problem and they do it faster than the teams who use bloated enterprise solutions.
I am tired of seeing over engineered enterprise solutions that that are implemented and never used because they can’t be integrated into the dev workflow easily. Simple bash script that does the task it was designed to do beats any enterprise crap.
The wisdom of pipes! I'd share these workflows the exact same way we share others [ie: BASH, Ansible]: Git. Needs nothing more than a directory, though an SSH daemon is quite nice.
Those of us who can survive without desperate monetization plays are worth quite a lot, actually. They say 'jury rig', we say 'engineer'.
The main problem with enterprise crap is portability. It only runs under very specific circumstances.
Bash and Perl scripts run, truly, everywhere - so you get real collaboration. I can share it with anyone on my team and they can use it.
Well written bash will run anywhere. Amateur bash will only run on the version of Mac OS it was written on, and even then only after the correct collection of random homebrew packages installed has been installed.
I agree, which is why I think most bash scripts should actually be Perl scripts. There, I said it.
> People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying
???
Mash 'em, boil 'em, put 'em in git, next to your code?
>I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software.
Complacent corporate teams. Agile teams need to simplify their workflows, and know that a Makefile can be better than some closed down, Cloud-first tool.
>That's who pays for all your tools to have free versions
Nah, we have free versions for stuff without enterprise editions too.
>People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying
It's that "no-one else" that doesn't bring value.
> (...) teams need ways to share their complex workflows (...)
Apps like Postman are the wrong tool for this purpose.
If you want to share workflows, let alone complex workflows, any automated test suite is far better suited for this purpose.
We are in the age of LLMs and coding agents, which make BDD-style test frameworks even more relevant, as they allow developers to implement the workflows, verify they work, and leave behind an enforceable and verifiable human-readable description of those workflows.
You put them in your repo or file server. No need to have all these accounts and potentially leaks/attacks
Git is pretty good at sharing you know
This could have been a 10 Megabyte TUI app in your terminal tab. Boggles my mind how even this kind of app manages to bring in Electron and the cloud.
Edit: Ah, so here it is: https://posting.sh
> could have been a 10 Megabyte TUI app
Wow, in a world dominated by gigabytes of electron application, people thinks 10 MB is the optimal size for a simple utility TUI app.
As a reference, (from archlinux repo), vim’s install package is 2.3MB, curl is 1.2MB, lua (the complete language interpreter) is 362KB
To be fair, Vim and Curl are almost certainly dynamically linked, so they get to "cheat" a little. 10 megs is entirely reasonable for a statically linked utility intended to "just work" when you dump it somewhere in your $PATH.
Take the Micro editor. It's written in Go, and packs a fair bit of functionality into a single 12 meg static binary (of which a few megs is probably the runtime.)
640K ought to be enough for anyone.
- Bill Gates.
And:
The world does not need more than 4 computers.
-Ken Olsen, or someone (in the mainframe days).
(Both are alleged / apocryphal quotes. :)
I believe the Ken Olson quote was that nobody needed a computer in their house, but that was a time where businesses were using terminal servers... it would have been interesting to see where that would have went, but we might be heading that way again since we own nothing and everything is a only a temporary license.
The second quote was "I think there is a world market for maybe five computers", and it's attributed to Thomas Watson of IBM saying it in 1943. The real quote is indeed from Watson, but in 1953, summarizing the sales projections of a specific model of machine, and noting that they actually sold 18 of them.
https://freakonomics.com/2008/04/our-daily-bleg-did-ibm-real...
Gates denies ever saying anything like the 640K quote, but it was possibly someone at Microsoft being salty about the 640K limit that IBM had imposed on the PC through its design.
Indeed. It is the enigma of success in an industry with no franchise value.
Wow, I've been looking for a postman/Bruno/foo replacement that I could use inside a remote ssh server or remote dev containers in vs code. This might be it!
> even this kind of app manages to bring in Electron
Probably because it began as an chrome addon before it was "standalone".
Before Chrome became its addon*
Oooh this is neat! I've been using hurl (https://hurl.dev/) for the last few years and while it's fun, I've ended up with a ton of text files floating around a folder instead of any kind of organization. Might have to try this.
Posting has been the most lucrative option for me so far, but it'll take me some time to get used to the keybindings.
Because enteprise type devs love this shit
Ah, yes, the cloud-dependent tool that forces you to pay per seat and log in for any type of collaboration is down when their cloud provider is.
Anyways, the folks have spoken, no need to double down. There are more than a dozen alternatives to it, and new ones are coming up.
I'm helping build a new one.
- Completely offline.
- Gives the ability to build reusable blocks (headers, query params, etc)
- Let's you document everything in Markdown.
- Imports your collections and cURLs.
And yes. It's completely free. With plugin extensibility for anyone to build/install whatever they want.
The CEO committed to open-sourcing it, as well as to not monetize on anything that doesn't introduce operational costs to the team.
A little bit of feedback, I could barely read any of the text in the interface as the contrast is almost zero and the font is unbelievably small. So I tried Cmd+ to zoom the interface, but nothing happened, so I tried Cmd, to open the settings to see if there was a zoom level or contrast setting, nothing happened. I like the idea of it, but it's totally unusable.
Hi! Thx for that. Can you please open an issue with a screenshot here: https://github.com/voidenhq/feedback
What you're saying doesn’t sound familiar whatsoever, but I'd really like to look more into it.
Voiden looks really promising, so I installed it to get started, and here's my hot takes so far before even using it.
* The text is tiny for my old eyes. I figured there's probably a setting for it and hit Cmd-, and found there's no settings UI whatsoever. No keyboard shortcut either it seems, and no help menu either, so no searching for "keyboard" with Shift-Cmd-/
* .void files may be markdown, but no markdown editor will recognize it as such. Maybe support .void.md as well. I also couldn't find any way to edit the markdown source of a .void file from voiden, which is a bit ironic for a tool that loudly advertises the markdown format as a central feature.
* Could there be a block that expands into the full URL of the request and parameters above it (or perhaps as args)? How about another that renders as a cURL command, which would cover POST/PUT/PATCH requests nicely too. My API documentation always has cURL request examples and I detest writing them by hand.
* While I'm suggesting blocks, one that renders the response headers/body to the preceding request would also be handy. It should support a placeholder response that gets replaced when the request is actually run (and perhaps a "save" button to persist it in the markdown). Responses get long, so maybe have a max-height for the block and make it scrollable
I'm actually really excited about Voiden and hope these can be addressed. It has a similar feel to Jetbrains' .http format, but an evolutionary leap beyond it. It also feels really raw and unfinished.
Hi, thx for the feedback! Testing the settings (including different themes and font sizes as we speak). Some tweaks are been made on the responses side as well. As per the rest of your comments, some of these things have been discussed or touched upon, others have been just added to the discussion board :)