jicea (u/jicea) - Readit News

jicea commented on Yaak, an intuitive desktop API client github.com/mountain-loop/... · Posted by u/jicea

gschier · a month ago

Hey, thanks for posting. I'm the creator of Yaak, so let me know if you have questions!

jicea · a month ago

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!

jicea commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice

yoavm · 2 months ago

The one thing I never understood about the Hurl format is why the response status code assertion happens at the request section and not under the `[Asserts]` section. I wonder what the rationale behind that is.

jicea · 2 months ago

A simple GET with a status code is just

  GET http://foo.com
  HTTP 200

You could write also

  GET http://foo.com
  HTTP *
  [Asserts]
  status == 200

HTTP serves as a marker of the response section

jicea commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice

3eb7988a1663 · 2 months ago

I think the idea is nice, but I am struggling for why I should use it. I write using Django, which has plenty of hooks for testing within the framework. Why switch to a tool which is blind to my backend and is going to create more work to keep in sync? At minimum, I lose the ability to easily drop into my debugger to inspect why a result went wrong.

There is probably something to be said for keeping a hard boundary between the backend and testing code, but this would require more effort to create and maintain. I would still need to run the native test suite, so reaching out to an external tool feels a little weird. Unless it was just to ensure an API was fully generic enough for people to run their own clients against it.

jicea · 2 months ago

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.

jicea commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice

dm03514 · 2 months ago

I just started using hurl a couple months ago.

For my uses it's great that it has both test suite mode and individual invocation mode. I use it to execute a test suite of HTTP requests against a service in CI.

I'm not a super big fan of the configuration language, the blocks are not intuitive and I found some lacking in the documentation assertions that are supported.

Overall the tool has been great, and has been extremely valuable.

I started using interface testing when working on POCs. I found this helps with LLM-assisted development. Tests are written to directly exercise the HTTP methods, it allows for fluidity and evolution of the implementations as the project is evolving.

I also found the separation of testing very helpful, and it further enforces the separation between interface and implementation. Before hurl, the tests I wrote would be written in the test framework of the language the service is written in. The hurl-based tests really help to enforce the "client" perspective. There is no backdoor data access or anything, just strict separation betwen interface, tests and implementation :)

jicea · 2 months ago

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!

jicea commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice

kalli · 2 months ago

This looks interesting. Longtime user of the Vscode-restclient, but have been moving over to httpyac lately for the scripting and cli use. Will take a look to see if hurl is a good fit.

One annoying thing I've found in testing these tools is that a standard hasn't emerged for using the results of one request as input for another in the syntax of `.http` files. These three tools for instance have three different ways of doing it:

* hurl uses `[Captures]`

* Vscode-restclient does it by referencing request names in a variable declaration (like: `@token = {{loginAPI.response.body.token}}`).

* While httpyac uses `@ref` syntax.

From a quick round of testing it seems like using the syntax for one might break the other tools.

[1]: https://hurl.dev/docs/capturing-response.html

[2]: https://github.com/Huachao/vscode-restclient

[3]: https://httpyac.github.io/guide/metaData.html#ref-and-forcer...

jicea · 2 months ago

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.

jicea commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice

QuiCasseRien · 2 months ago

interesting tool !

première fois que je vois qqch de cool sortir d'orange.

jicea · 2 months ago

Ah ah ah thanks for this! There are a lot of Open Source projects from Orange => https://github.com/Orange-OpenSource

jicea commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice

mrcarrot · 2 months ago

> 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.

Is there a different POST request in the readme or are you saying that this example is going to send the "user" and "password" params in the request body?

> POST https://example.org/login?user=toto&password=1234

That seems really surprising to me - how would you then send a POST request that includes query string parameters? The documentation on form parameters [1] suggests there's an explicit syntax for sending form-encoded request parameters

[1]: https://hurl.dev/docs/request.html#form-parameters

jicea · 2 months ago

Ah sorry for both, the README sample is here from the start (4 years) ago that I didn't take time to read it with a fresh eye:

  POST https://acmecorp.net/login?user=toto&password=1234

In the README is doing a POST request with user and paasword parameter in the URL.

  POST https://acmecorp.net/login
  [Form]
  user: toto
  password: 1234

Is a more traditional POST with user and password in the body. Probably going to update the READMEs sample Issue created here [1]!

[1]: https://github.com/Orange-OpenSource/hurl/issues/4151