Use interface for http client

[martin-hanzl]

Currently .Client() accepts *http.Client. Would it make sense to accept an interface with Do(req *http.Request) (*http.Response, error), to support custom clients?

I have a client which handles retries and other resiliency features and I'd like to replace the default client with it.

[earthboundkid]

You should use requests.DoerTransport to turn a non-http.Client Doer into a standard http.RoundTripper.

See the discussion on the PR here: #70

[TuringJest]

In my opinion using transports for everything non-transport related is an anti-pattern.
It introduces more surface for potential bugs and the quirks of the bad documented transport part of net/http.

You might run into issues with things like chaining transports, than it's not immediately clear what net/http does before transports or after. E.g. using a cookie jar in a transport is not straightforward because evaluation of the jar happens before the transport part.

It's much more straightforward and more "go like" to simply wrap up your own client.

[earthboundkid]

All I know is the OAuth transport comes from the Go team, so it must be at least a semi-expected usage. I think if there's ever a net/http/v2, it should probably clarify the difference between Clients and Transports, but for now, the ecosystem is what it is, and Doers are much less common than Transports.

[TuringJest]

Not the best example because OAuth doesn't use cookies.
I'd just argue that using clients is probably more flexible and easier because the behaviour and expectation of a client is clearer vs. transport. Having to sift through net/http's source to find out why fetching cookies fails (or other unintended transport use) might go against the idea of this libs idea of simplification.

[earthboundkid]

Using a Doer is not clearer because http.Client also handles redirects and default timeouts. If you implement Doer, you must take on those responsibilities, which is harder than just intercepting a single request. I appreciate that the documentation of this is not great, but this is how the Go ecosystem has consolidated over the last decade. There are a few packages out there that implement Doer but they are a distinct minority compared to Transports. Making a change to Requests to use a Doer was evaluated before and found to be infeasible without breaking backwards compatibility and jeopardizing the functioning of the existing Transports. If you have a concrete PR that can expand the use of Doers without breaking Transports, I will consider it, but there's no point in going in circles about a decision that has already been made.

[TuringJest]

Sorry for the late reply. You are right. The issue is just that some things don't work well with transports, but I'm using your package to create requests for my doers, which works well. So it's not too bad, it would just reduces some more redundancy.

Will check if I can implement something useful as soon as I can get at it, without turning the code upside down or making it too complicated.
Probably shouldn't be an issue to chain your current transports with a custom client's transport, as long as they use the standard resps and reqs.