[ken]

This is neat, but also seems like a code smell. Do people really need to convert between HTTP request formats/languages much? When I see many independent implementations of an N-to-M mapping, it looks like the perfect use case for a standardized interface, like a DSL.

In fact, can't HAR do this? I'd love to be able to just pass a HAR string to any HTTP client library, and have it execute that. Or call "dump_har()" (or "--dump-har") on any client, and have it spit out HAR that I can take it to any other client.

[eat_veggies]

When reverse engineering or automating an API my workflow will often look like this:

1. Open browser inspector, watch API requests for one I'm interested in

2. Right click, "Copy as cURL"

3. Paste into a text editor, remove some unnecessary headers, re-running the curl command to verify that the headers I removed aren't important

4. Convert into python requests so that I can play with the parameters

[ShakataGaNai]

100% this. I do a lot of small automations against various API's (or sometimes against systems that don't API's at all) and have used this same workflow many times.

Also handy because even well documented API's don't have examples in every language, but most do have examples in curl. So you can easily take those example curl's and dump them out to something programatic in your language.

[ken]

Right, and Firefox and Chrome both have "Copy as HAR". That should save a step, right?

Plus, you probably have a text editor that knows about JSON, so it's easy to (say) remove keys from a JSON file, or even just keep the keys on separate lines and add/remove entire lines. I haven't seen a text editor (even Emacs!) that was as good at editing shell command parameters. It's a lot easier to quote special characters for JSON, too, compared to quoting special characters for my shell.

[dmurray]

HTTP is the standardized interface. If you wrapped it in a prettier DSL, people would still have to take raw requests and figure out how to make them in the DSL.