I remember when postman used to bring little envelopes (sometimes little boxes) to people’s homes and was paid by tax money and the small amount of postal fees we paid.
Go back to the future:
https://addons.mozilla.org/en-US/firefox/addon/rester/
I also use Bruno: https://github.com/usebruno/bruno
So much work and investigation into a tool that is a front end for something already on your system.
I feel like people who make these arguments in earnest are simply terrible at change and lack empathy. “Works for me, so I refuse to understand why it doesn’t work for me”. It’s so conservative neckbeard and offputting.
That does not really work for DX… Or collaboration. Or testing. Or documentation.
Na, that is you not reading the Frequently Asked Dumb Questions
Q: What about team collaboration?
A: It’s a text file. Put it in Git. You know, that thing you should be using anyway? Now your requests have version control, code review, and diffs. For free. Revolutionary, I know.
Q: But Postman has testing and automation!
A: So does cURL in a shell script with || and && and actual programming languages. You want assertions? Pipe to grep or write a 3-line Python script. Done.
Soooo you’re not actually arguing for cURL but for bash scripts and potentially something else.
And now you come across all the issues that come with that, like portability, the inevitable messiness of Bash (and the fact that people actually need to learn it unlike a GUI tool that uses simple JS for scripting), and you lose all the convenience of a nice UX and stuff like validation that comes with it.
In other words your argument is about as valid as people who argue that vim is the peak of IDEs and noone ever needs anything else. Which - I really hope - you realize is a bit crazy.
But how do you collaborate?
Q: What about team collaboration?
A: It’s a text file. Put it in Git. You know, that thing you should be using anyway? Now your requests have version control, code review, and diffs. For free. Revolutionary, I know.
expose a backdoor endpoint on every collaborator’s device and peruse their shell history
I just wish that they wrote more articles. Their writing style is superb. Can’t argue with this though:
More coming soon. Or not. I don’t owe you shit.
Never had any use case for collaborating on requests, why do you use it?
When you explore an API in a team and would like to collaborate on that with somebody. If you’ve worked on any big tech API, with Oauth, and have secrets, writing a script for every request combination takes way too long. Simply pasting the URL and using the stored oauth token within the session is easy with a frontend. And it’s reusable and sharable within your team.
I see. Thanks!
Our team lives in Git, our communication is happening on slack, our docs written and maintained on confluence and after some time they always drift away from the actual requests inside Postman.
So we built and open sourced Voiden a few months ago: an API tool where all that: specs, tests, context and docs are always together in the same executable plain text file (markdown). We also made this Git native so that every change is versioned and tracked just like code.
The last change we have made is to add a Runner so that one can run the files directly from the terminal and CI/CD pipelines.
here is the tool: https://voiden.md/download repo: https://github.com/VoidenHQ/voiden
welcome to try and give feedback!
That looks pretty nice. The documentation said it fears me.
TL;DR;
Why developers are abandoning Postman and its clones?
Enshittification
Didn’t read the article, but that’s why I abandoned it.
I started using bruno for lazy gui “make a request” needs.
But for anything serious python requests is right there, so I mostly used that for testing.
I’ve taken to writing .http files which are runnable on a number of IDEs and plugins. I don’t need to know what anybody else is using to run them, they live with the code and I’m happy.
That said, I’ve seen people on QA do really cool end-to-end tests at load via very approachable scripting on Postman.
There’s lots of room for “to each their own” here.
