I'm currently using Bruno, which uses its own format "Bru Lang" for storing HTTP requests as plain text[1]. The VS Code extension is great but I'd much prefer the standard backed by 30k+ stars was extended instead of a new format to introduce fragmentation in this space.
Im a bit flabbergasted I haven’t yet found a HTTP/API client that simply runs off an oAPI spec. Sure, most support «import of..», but do any support oAPI’s as continuously evolving source of truth?
Our oAPI spec is auto-generated (based off ts-rest.com contracts), and I’d love one that understands this, including auto-refreshing/importing of spec when it changes on disk.
If anyone knows of this magical piece of software, please share!
Thank you all for showing interest in this project. You described exactly what motivated me to create this language – support for OpenAPI specs. I just wanted to have a language where I could import an OpenAPI spec and leverage the intelligence, because, like you, in all my projects the specs were autogenerated.
Yeah, I agree. Bruno is a great tool, but it's missing one key component that I needed (maybe it's just me) – it can't run multiple requests in a chain. Also, constructions like:
get {
url: ....
}
feel too verbose to me, I wanted something clearer, like:
get /users
;)
But in general, thank you guys for your interest, my goal is to gain that 30k+ starts )))
It was funny that when I was in the middle of the project, I discovered Hurl. It was cool, especially since it's written in Rust and uses libcurl under the hood. However, the lack of OpenAPI support and VS Code integration forced me to continue working on HTTL project.
Seems like it? Except curl already has decent syntax and lets you directly control what you're doing so you know what the generated request is going to look like. No magic.
I can't see how these tools are powerful enough to replace curl, so you still need to know how to use curl, but at the same time this DSL isn't self explanatory.
I'd rather just use curl, and my team will be careful I didn't ask them to learn another DSL. They already know how to use curl.
It looks really nice!
What I found challenging is the lack of namespaces for example using two different bases or two different OpenAPI specs that may override each other or be suggested in the autocomplete in the wrong situations
I'm currently using Bruno, which uses its own format "Bru Lang" for storing HTTP requests as plain text[1]. The VS Code extension is great but I'd much prefer the standard backed by 30k+ stars was extended instead of a new format to introduce fragmentation in this space.
[1]: https://docs.usebruno.com/bru-lang/overview
Referring to OpenAPI: https://github.com/OAI/OpenAPI-Specification
100%, this.
Im a bit flabbergasted I haven’t yet found a HTTP/API client that simply runs off an oAPI spec. Sure, most support «import of..», but do any support oAPI’s as continuously evolving source of truth?
Our oAPI spec is auto-generated (based off ts-rest.com contracts), and I’d love one that understands this, including auto-refreshing/importing of spec when it changes on disk.
If anyone knows of this magical piece of software, please share!
Thank you all for showing interest in this project. You described exactly what motivated me to create this language – support for OpenAPI specs. I just wanted to have a language where I could import an OpenAPI spec and leverage the intelligence, because, like you, in all my projects the specs were autogenerated.
Yeah, I agree. Bruno is a great tool, but it's missing one key component that I needed (maybe it's just me) – it can't run multiple requests in a chain. Also, constructions like: get { url: .... } feel too verbose to me, I wanted something clearer, like: get /users ;) But in general, thank you guys for your interest, my goal is to gain that 30k+ starts )))
It looks similar to https://hurl.dev
Hurl is well designed for testing with marchers available for assertions. HTTL only supports strict equality assertions (for now).
Hurl is written in Rust, HTTL in node.
HTTL has an import system that can be useful for reusing an auth setup.
It was funny that when I was in the middle of the project, I discovered Hurl. It was cool, especially since it's written in Rust and uses libcurl under the hood. However, the lack of OpenAPI support and VS Code integration forced me to continue working on HTTL project.
Hi maintainers of Hurl here! We started very small also and HN helps us a lot to grow and gain popularity. Keep up the good work and the motivation!
The only advice I'll humbly give is to choose a "traditional" license, unless there is a very strong motivation to have a custom one.
I feel like I'm slow reading through the docs. I really tried.
Is this just curl with a simpler syntax? This is advertising CLI integration, so what's the VSCode feature people seem excited about?
Seems like it? Except curl already has decent syntax and lets you directly control what you're doing so you know what the generated request is going to look like. No magic.
I can't see how these tools are powerful enough to replace curl, so you still need to know how to use curl, but at the same time this DSL isn't self explanatory.
I'd rather just use curl, and my team will be careful I didn't ask them to learn another DSL. They already know how to use curl.
It looks really nice! What I found challenging is the lack of namespaces for example using two different bases or two different OpenAPI specs that may override each other or be suggested in the autocomplete in the wrong situations
HTTL looks really nice
Thank you so much :)