Http Client CLI Size
Hi,
Preamble. We use HTTP files quite a lot for our local development, including in our contract test solutions. We use both Rider (mainly during the development phase) and a utility called httpyac when running tests in our CI/CD pipeline.
The reasons we don’t use the ijhttp tool are its dependency on Java and its larger size compared to httpyac. The problem we face now is importing stuff. What works well with the import operator in Rider doesn't work in httpyac which needs to call the require() method instead. We also failed to make it work with require in Rider.
Eventually, we started considering the option of completely switching to ijhttp, but its dependency on Java and its size are issues we hope will be improved.
I’m not sure how feasible the idea of rewriting the entire tool is, but looking at the industry and tools like Hurl, I would say that the .NET ecosystem still has room for improvement.
Hope this request makes sense.
Please sign in to leave a comment.
I'm afraid we cannot so far reduce the size of the tool. However, HTTP Client CLI can be run in a Docker container - would this work for you? If not, could you please describe your testing flow in a bit more detail and specify what exactly you are using import/require for?
Do I understand correctly that you'd like to request a syntax change so require can be used instead of import in HTTP files run with ijhttp? I'm not sure that would be possible, but still would be grateful to learn more about scenarios affected by this difference. Thank you!
The size of the docker image is still 300+ MB
>what exactly you are using import/require for?
For instance, constants - something we don’t want to overload the client.env.json with.
>that you'd like to request a syntax change so require can be used instead of import
I am not sure if this is the best approach. I wouldn't say we cared about import vs require if the tool/image size was really smaller.
We need to consider factors such as size, rate limiting, and other things that may eventually impact the costs our organization pays to GitHub, cloud providers, and similar services. We understand that there are many API testing tools that probably solve this problem better, but since our developers chose to use .http requests, we decided to follow that approach as far as we can.