Lectures

We break down the practical mechanics of HTTP requests in Go: why you need a reusable http.Client, what the Request → Do → Response cycle looks like, why err does not mean 404, and exactly where defer must be placed for resp . Body . Close(). At the end: typical mistakes and an example wrapper TaskClient around the client.

Let’s break down how to properly limit the time spent on HTTP requests in Go: a global “fuse” via http.Client . Timeout and targeted per-operation limits via context . WithTimeout. We’ll show which one “wins” if you set both timeouts, how to distinguish a timeout from a cancellation with errors . Is and the reasons context . DeadlineExceeded/ context . Canceled, and we’ll also build a client skeleton for the tasks API with sensible time budgets.

We break down how to properly build an HTTP request in Go using http.NewRequestWithContext: why a request needs context.Context (timeouts, deadlines, cancellation), how to safely form query params via net/url instead of string concatenation, and how to set the Accept, Content-Type, User-Agent headers before calling client.Do(req). At the end, there is a request assembly diagram (mermaid) and a set of common mistakes.

We break down why, in net/http, 404/ 500 responses arrive as a normal resp with err == nil; how to safely read an error body exactly once using io.LimitReader; how to try parsing a JSON error envelope; and then return a typed * HTTPStatusError that is convenient to detect via errors . As.

We break down when retries are actually appropriate: how HTTP method idempotency affects retry safety, why a shared time budget via context.WithTimeout matters, how to limit the number of attempts and delays, how transport errors ( err from Client.Do) differ from unsuccessful statuses ( resp . StatusCode), and why it is critical to close resp . Body on every request. At the end — a retry-loop diagram (mermaid), an example retry helper for GET in Go, and common mistakes that lead to duplicates and request storms.