A few of us had a very short discussion on the subject here:
https://groups.google.com/forum/#!topic/golang-nuts/rjYdaFM5OBw
Almost all go code I've seen that requires an HTTP client takes an
`*http.Client` as one of the parameters. This doesn't leave consumers with
many other options than to leverage the `http.RoundTripper` interface that
is consumed via `http.Client.Transport` and implemented by
`http.Transport`. I've seen a great deal of success in using that interface
to implement resiliency features like retries even though the documentation
explicitly forbid using the `http.RoundTripper` for that purpose. My team
has fallen to using a decorator pattern where we define all new
functionality as an `http.RoundTripper` and apply it with a
`func(http.RoundTripper) http.RoundTripper`. Ex:
var client = &http.Client{
Transport: Retry(TImeout(Log(&http.Transport{}))),
}
On Sun, Dec 10, 2017 at 1:19 PM Alex Buchanan <buchanae.o...@gmail.com>
wrote:
> I'm considering adding http client retries to an existing library, owned
> by someone else, in order to add resiliency to errors such as http 503. I'd
> like to keep the changes as minimal as possible, with maximum effect, as
> usual. I'm eyeing http.Client.Transport. Possibly I could use that to wrap
> the DefaultTransport, intercept responses, check the code against some
> rules, and retry on failure.
>
> Am I on the right track here?
>
> Thanks,
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
