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: https://www.usebruno.com/

+ 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

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