Bug report for `trillium-client`: `ClientLike` doesn't allow `Into<Url>` like `Client` does
joshtriplett opened this issue · comments
The methods of trillium_client::Client (get, post, etc) accept anything implementing TryInto<Url>. However, the methods of trillium_client::ClientLike require an Url, which makes them less convenient to use. At the next breaking release of trillium_client, please consider making the trait methods have the same signature as the inherent methods, so that passing a &'static str works.
It's been a bit since I wrote that, and it's mostly a vestige of semver at this point. I'm curious how you're using it, though, because my inclination would be to remove it entirely. If I recall correctly, ClientLike was written to be object-safe as a dependency-injection mechanism for testing (Arc<dyn ClientLike> or similar) but I ended up far happier using a faux Connector, since that's already object safe and boxed inside of the Client. If that's a similar reason you're looking at ClientLike, trillium_testing::ServerConnector is quite convenient, since it supports writing mocks using trillium Handlers, and fully exercises the http client. Are you using the trait as bounds on a generic? What's the other impl ClientLike you're using?
After some further investigation, you're right, TryInto<Url> would not actually solve the problem I had.
The actual problem I'm trying to solve: I have a wrapper around Client that provides get/post/delete/etc methods that just take a path, and inject a base URL (https://server.example/) and an authentication header.
Right now, that wrapper has to manually follow the same pattern Client does, implementing separate methods for get/post/delete. The value I was hoping to get out of ClientLike was implementing one method (build_conn) and then getting all the others for free. But that doesn't actually work, since I can't take a generic TryInto<Url> and parse it as a relative URL.
This would probably best be solved another way. surf supported setting a base Url; perhaps Client could support something similar, which would solve that half of the problem.
For consistently adding headers, perhaps Client could support supplying a Fn(Conn) -> Conn to be applied to the return value of build_conn?
Closing this issue now, because the new "base" mechanism completely supersedes this.