It's not necessarily better, just a different interface that scales better to complex requests.

curl command lines can get huge and unwieldy. If a curl command has a huge amount of input, that gets unwieldy, too. Same thing with data input.

The fact that your requests persist and can be repeated and modified is useful. Better than looking up past commands in ~/.bash_history.

Ha, I feel the same way and started to make a little tool to help this, but most of the feedback I got was that it was pointless :( https://github.com/seiferteric/clamp

this is really cool! Great work.

Better than saving those requests in curlrc and recalling them with --config?

If you are quick with cURL maybe it's not--it's just a matter of preference.

I, on the other hand, can take quite a while to type out a cURL request with 4 custom headers and a long JSON body.

While I spent most of my day at the CLI I do step out for a few choice applications. Being able to quickly save and compile a bunch of requests to replay is also nice though I'm sure you could do that with cURL or similar tools.

It doesn't hurt that the app is particularly nice looking either :-)

Yeah, JSON on the command line can be a big PITA, especially when it comes to escaping. The old `curl -vvv -X POST --data @foo.json http://example.com` trick mostly works, but isn't the most elegant thing in the world.

This just might be, and it'll write the curl command for you too :)

Agreed. On a more positive note.. jq absolutely blows my mind for working in the other direction (reading)

jq: http://stedolan.github.io/jq/

jq is small peanuts compared to App::RecordStream.

https://metacpan.org/release/App-RecordStream

https://metacpan.org/pod/App::RecordStream::Manual::Story

https://metacpan.org/pod/App::RecordStream::Manual::Examples