Why not a Client trait?

[anderspitman]

This is probably my lack of Rust knowledge showing, but I noticed that async_impl, blocking, and wasm all define their own Client structs, then compile flags are used to select which one to use at runtime.

Why not define a Client (and probably AsyncClient) trait with a common interface and implement it for each concrete type?

Wouldn't this also make it possible for 3rd-party crates to implement alternative clients?

[seanmonstar]

The trait I recommend people use is from tower::Service, which is implemented for Client: https://docs.rs/reqwest/latest/reqwest/struct.Client.html#impl-Service%3CRequest%3E-for-Client

[anderspitman]

Ah I missed that. Nice! This won't work for sync clients, right?

[seanmonstar]

Correct, it's async.

[anderspitman]

@seanmonstar I think I was confused before. After reading up on tower::Service and looking at the implementation for Client, if I understand correctly that would allow you to use Client as a middleware that makes requests. Is that correct?

What I'm trying to accomplish is actually the opposite. I'd like to be able to provide reqwest with a tower::Service which is capable of making HTTP requests, and have reqwest use that service as it's "backend" for making requests. This would make it easy to provide custom backends for reqwest, but still get all the nice features it provides.

For a bit more context, I'm trying to get reqwest to run in wasm32-wasip1, so I can use it in Extism plugins. I believe this is currently failing because reqwest tries to dial the network connection directly, and wasip1 doesn't support that. Extism provides a simple HTTP request host function that would be simple to wrap in a tower::Service.