I use cURL a ton too, for when I want to make a one-off request, examine the response, and then throw it away. Here are some reasons why I'd reach for a tool like this:
• I want the history of every request and response to be saved by default, so if I ever need to look back to one I know it's available
• I'm sending several similar requests and I want them to share a set of variables, or, I want something in the response of one request to be used as a parameter when sending another
• I want to set a URL parameter with a bunch of symbols in without worrying about quoting
• I have so many types of requests that I'd like to organise them in a tree
• The JSON returned in a response is absolutely massive and I'd like to expand/collapse subtrees instead of viewing the whole thing as unhighlighted text
>• I want the history of every request and response to be saved by default, so if I ever need to look back to one I know it's available
Requests are saved in .bash_history and easily greped from the command line. With fzf, it's addictively good. Responses are not saved, but it's not something I miss, but it could just be a lack of habit of mine.
>• I'm sending several similar requests and I want them to share a set of variables, or, I want something in the response of one request to be used as a parameter when sending another
Again, bash, a bit of scripting for me goes a long way.
>• I want to set a URL parameter with a bunch of symbols in without worrying about quoting
That's a good one. I usually end up resorting to a real programing language like PHP or Python when I begin having to scape special characters much
>• I have so many types of requests that I'd like to organize them in a tree
Haven't felt the need, again, could be lack of habit.
>• The JSON returned in a response is absolutely massive and I'd like to expand/collapse subtrees instead of viewing the whole thing as unhighlighted text
Same here. Curl, bash, jq, etc. But of course not everybody is comfortable on the command line. I notice a lot of frontend developer seem less familiar with that stuff, for example. Non technical people are typically also not comfortable with UI based tools for this.
The exception for me is stuff like graphql. It's nice to have some code completion for that since it is so fiddly and verbose. Likewise, I use Elastic's dev console to interact with Elasticsearch/opensearch.
Otherwise, I avoid doing a lot of manual requests to anything. Most of my systems end up having some kind of admin UI. I don't want people faffing about with curl commands to do routine stuff and then messing it up and creating a mess. That just doesn't scale. Building a UI usually implies building a good api client. I've also scripted together a simple cli in the past with just curl and some bash commands. A bit more work but nice once you have it. The downside of cli is that only techies can use it. Having a ui means you can hand off responsibility to less technical people or customer support. So that actually reduces my workload. Postman, SoapUI, and whatnot are too low level for that. And once you have a decent API client, you can also use it to write good tests that don't just copy/paste a lot of http stuff around.
I once had a test engineer that insisted on writing tests using SoapUI (which as the name indicates was originally intended for testing SOAP stuff but eventually evolved to do REST stuff). Big PITA to deal with these tests because they were highly flaky and he just copy pasted shit around in SoapUI so it took ages to fix anything. Also asserting anything useful was also a bit limited. Basically any trivial change you made to the code, dozens of those tests would fail. The more tests he added, the worse it got. We eventually replaced those tests with a proper API client and integration tests that we could actually refactor in a sane way and run concurrently. The result more, better, and faster tests.
There are already many tools for many things in the Linux base userland, installed per default. Mankind could save many CPU cycles and developer days if we'd be able to read the existing documentation and learn to use them.
But instead we are here, people are baffled if projects run on bare Debian with no extra dependencies as if it was some kind of magic.
It's easier to do the OpenID authentication dance with a tool vs curl (especially when doing PKCE requests), and I use Postman to build up some documentation for my APIs.
