Errors, Timeouts, and Retries

Errors

Part of: Your First API Call

Your first ten lines of code assumed every call succeeds. Real networks don't. Servers hiccup, keys expire, you send too fast, a request hangs forever. The difference between a toy script and a reliable app is what happens when the call fails . The good news: failures come in a small number of named buckets, and each bucket has a standard response. What it is When a request fails, the API returns an HTTP status code : a three-digit number that classifies what went wrong. You met a few in lesson 3; here is the working set: - 200 : success. Your answer is in the response. - 400 : Bad Request. Your fault: malformed JSON, a missing field, a bad parameter. Retrying won't help; fix the request. - 401 : Unauthorized. Your API key is missing or wrong. Retrying won't help; fix the key. - 429 : Too Many Requests. You hit the rate limit. Retrying after a wait is exactly right. - 500 / 503 : the server had a problem or is overloaded. Not your fault; retrying after a wait usually works. A separate failure is a timeout : the request takes too long and your client gives up waiting. No status code at all, the answer simply never arrived. How it works The crucial split: which errors are worth retry

Challenge: Backoff Scheduler