When would you use this over just curl? Genuine question. I like plain text where I can use it, but don't understand the benefit of this over curl.
- chaining requests,
- passing data from a request to another (with captures or with cookies, each file being its own cookie session),
- gettings resources and checking payload SHAS
- checking responses (JSONPath, XPath on body response, headers etc...)
- retry / polling scenarios (polls until a resource is created for instance)
- comments things (we use Hurl as documentation for APIs workflows)
You can do these things using scripts and curl of course. We appreciate having a tool that works locally on Windows / macOS / Linux and integrates nicely in CI/CD. Hurl uses a (very small) fragment of libcurl. curl is much much powerfull, we love it.
Are cookie jars not sufficient for that? Curl supports those on its own.
- chaining - It's just code so put multiple get calls after one another - captures - Just variables. With sessions you can also get automatic cookie-capture. - Payload - Yes - Parsing responses - stdlib has json and xpath libraries that also can be written as oneliners. Html not always being pure xml is a problem, but can be solved with other libraries, like beautifulsoup. - Retries - a bit more hassle to set up but also doable with relatively small effort. - Comments - yes
What's missing would be benefits given by the declarative nature, such as more human friendly output on jsonpath assertions. But that's often easily extended with functions in the test framework and outweighed by the flexibility given by allowing you to extend the capabilities with more functions or put computations between chained calls or other external inputs/outputs needed in the tests. How often do you really need to test only the http call and nothing else?