Hi maintainer of Hurl here, thanks for the link; Hurl is using libcurl as its HTTP engine (you can for instance use --curl to get an export of curl commands). In a few words, if you just use Hurl, you just use curl also...
If you're willing to use a CLI, you can try Hurl [1]. It's is an Open Source cli using libcurl to run and test HTTP requests with plain text.
We use libcurl for the reliability, quickness and top features (HTTP/3 IPv6 for instance) and there are features like:
- requests chaining,
- capturing and passing data from a response to another request,
There is nice syntax sugar for requesting REST/SOAP/GraphQL APIs but, at the core, it's just libcurl! You can export you files to curl commands for instance. (I'm one of the maintainers)
Postman is currently down: it gives you time to try Hurl [1] an open source CLI to tests APIs/HTTP request s with plain text. Hurl is built on curl, so it's super reliable, designed to be used in CI/CD. Give it a try!
I'm sorry I must be really tired I don't understand certains animations when playing programs: in the first program, the 3rd instruction is 'PRINTI $0'. The instruction description is "print the integer stored in $a to the console". We have a first animation, a 0 that goes to the console, and a second animation, a 0 that comes from memory... Is the order right? What does represent the second animation? I must miss something obvious here....
Would be super cool if we could run programs step by step also!
The app is really super clean, I like it a lot (compare to Bruno for instance, one of your "competitor"). I see in the README that "Yaak is open source, but only accepting contributions for bug fixes.". It's an understandable statement, but it seems that there is also no way to post issues on the GitHub repo. Is there any reason for this (people could post issues without ever wanting to contribute imo). Anyway good job, I hope you'll get some traction!
We used Hurl to go from a ktor web server to a spring boot rewrite (Java/Kotlin stack). It was a breeze to have a kind of specifications test suite independent of the server stack and helped us a lot in the transition.
Another benefit is we built a Docker image for production and wanted to have something light and not tight to the implementation for integration tests.
Maintainer here, thanks for the feedbacks. 6-7 years ago, when we started working on Hurl, we started with a JSON then a YAML file format. We gradually convinced ourself to write a new file format and I completely understand that it might feel weird. We tried (maybe not succeeded!) to have something simple for the simple case...
I'm really interested by issues with the documentation: it can always be improved and any issues is welcome!
Guilty to have created yet-another-format for HTTP client! To "mitigate" this issue, you can use `hurlfmt` (distributed along `hurl`) that would allow you to export a Hurl file to JSON. You could then go from this JSON to another... It's not magic but it can help if you're going to change from Hurl to another thing.
Obviously better IDEs integration, support for gRPC, Websocket would be very cool.
A favorite of mine is to be available through official `apt`: there has been some work but it's kind of stuck. The Debian integration is the more difficult integration we have to deal. It's not Debian fault, there are a lot of documentation but we've struggled a lot and fail to understand the process.
Hurl works only on the HTTP layer, there is no JavaScript engine. If your modal open a form that will trigger some kind of XHR, you'll "simulate" the HTTP traquets that the form modal could have done. Hurl is not a kind of Playwright for instance.
The POST in the README is going to send the params in the request body "url form encoded" like a form in a web page. There are more samples on the doc site [1].
Regarding curl, Hurl is just adding some syntax to pass data from request to request and add assert to responses. For a one time send & forget request, curl is the way, but if you've a kind of workflow (like accessing an authentified resource) Hurl is worth a try. Hurl uses libcurl under the hood and you've an option `--curl` to get a list of curl commands.
We're trying to write "simple" Rust as far as we can, without going into too much optimisation: very little lifetime usage, no async stuff (just classic multi-thread directly from the last sample of the Rust book), liberal usage of clone, no macros, reusing crates for C libcurl and libxml binding, limiting dependencies. We could certainly gain a lot of performances but with this first simple approach, the binary is already "fast"... The only advice I would give for someone going into Rust is to not try to optimise everything from the start to get a first "feeling" of the language.