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 tha

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.