It makes no sense in the first place for such a tool to even need a login functionality and cloud saves... What's really needed to store information about a few http requests? Maybe a few kilobytes. I never understood it and I particularly don't understand how any company could fall for that. If they instead invested in teaching their engineers how to use curl even that would have paid off more.

The benefit of using postman is that you can open the app, see your (shared) collections, easily change the params and hit send. Can curl be used like that?

You can use hurl which uses libcurl. You can save it to git and commit your hurl testa in the same repo.

It's not very fun to run the auth call, then copy and paste the access token to the next call, and have to update all of your curl cmds all the time... Even if you use env variables, that's a horrible way to use env variables.

You’re making the case for automation, which happens to be something the shell excels at. Use unexported shell variables or command substitution (e.g., “$(pbpaste)”). Directly use the result of the auth call without going through the clipboard if possible. Create a shell script if shell history isn’t enough. Use interactive notebooks if you need something more advanced. The possibilities are infinite.

At this point, just write a script

Or perhaps write a script that has some kind of GUI.

Or maybe make the gui run the URL

You're right the possibilities are endless. And this Bruno and postman or permutations of that endlessness.

If I understood correctly, you claimed that saving requests, modifying it, or parametrizing it was somehow more cumbersome to do with curl than with a GUI. I was just pointing out that the shell is literally designed for all those use cases. And human users don't interactively use curl without a shell.

Also, using curl and the shell allows you to progressively iterate. So "write a script at that point" was kind of the point. Though you don't need to go that far to just feed authentication info.

GUI solutions don't have endless possibilities. You start and end with the exact same tool. The clicks and form fillings can't easily be copied around and iterated on unlike commands in a REPL. You can only perform tasks defined by the author of the application.

This feels along the lines of the infamous Dropbox comment

I was responding to a claim that essentially boiled down to shells can't parametrize input. How is it even remotely comparable to "the infamous Dropbox comment" to point out that shells can do that better than GUI tools?

Also expecting end users to develop their own file syncing solution on top of FTP is unreasonable. Expecting software engineers to be able to use curl instead of a GUI form is not.

You've the exact same attitude. If something is easier and more convenient then people will use it

By attitude, you mean not agreeing with every negative comments made about curl regardless of its accuracy. It guess it was just a thinly veiled insult for not being on the "right" side, then.

These tools are Mad Libs for curl commands presented as GUI forms. It does a subset of what curl + shell does while requiring more clicks. The target demographic are people who need to know the tool it's meant to replace in order to do their jobs effectively. That not easier or more convenient in my book.

You're describing the same tool with a much worse UI of recreating the tool yourself (by everyone). There is much value in avoiding that, hence people use integrated tools even with the risks of lock in

What UI do you need to recreate and how is it "much worse?" You essentially type in the same information with curl, but without all the mouse clicks and cursor movements.