`pester` wraps Go's standard lib http client to provide several options to increase resiliency in your request. If you experience poor network conditions or requests could experience varied delays, you can now pester the endpoint for data.
- Send out multiple requests and get the first back (only used for GET calls)
- Retry on errors
- Backoff
### Simple Example
Use `pester` where you would use the http client calls. By default, pester will use a concurrency of 1, and retry the endpoint 3 times with the `DefaultBackoff` strategy of waiting 1 second between retries.
```go
/* swap in replacement, just switch
http.{Get|Post|PostForm|Head|Do} to
pester.{Get|Post|PostForm|Head|Do}
*/
resp, err := pester.Get("http://sethammons.com")
```
### Backoff Strategy
Provide your own backoff strategy, or use one of the provided built in strategies:
-`DefaultBackoff`: 1 second
-`LinearBackoff`: n seconds where n is the retry number
-`LinearJitterBackoff`: n seconds where n is the retry number, +/- 0-33%
-`ExponentialBackoff`: n seconds where n is 2^(retry number)
-`ExponentialJitterBackoff`: n seconds where n is 2^(retry number), +/- 0-33%
```go
client := pester.New()
client.Backoff = func(retry int) time.Duration {
// set up something dynamic or use a look up table
return time.Duration(retry) * time.Minute
}
```
### Complete example
For a complete and working example, see the sample directory.
`pester` allows you to use a constructor to control:
I did this for watching for FD leaks. My method was to alter `sample/main.go` to only run one case (`pester.Get with set backoff strategy, concurrency and retries increased`)
and adding a sleep after the result came back. This let me verify if FDs were getting left open when they should have closed. If you know a better way, let me know!
I was able to see that FDs are now closing when they should :)
![Are we there yet?](http://butchbellah.com/wp-content/uploads/2012/06/Are-We-There-Yet.jpg)
Are we there yet? Are we there yet? Are we there yet? Are we there yet? ...