HTTP, DNS, REST & JSON

1 · What happens when you hit a URL essential

Here's a moment you've probably had without noticing. You type an address, hit Enter, and a page appears — feels instant, feels like magic. But the day it doesn't work, that magic turns into a wall: "DNS_PROBE_FINISHED", "connection timed out", "certificate invalid", "502 Bad Gateway". Each of those errors is naming a different step that failed — and if you don't know the steps, every one of them looks like the same unhelpful "the internet is broken". This section hands you the map so those errors start telling you exactly where to look.

Think of visiting a friend in a city you've never been to. First you need their address — the name "Priya's place" is useless to a taxi, so you look it up in your contacts (that's DNS turning a name into a number). Then you actually travel there and make sure the door's the right one and the line is private (that's TCP opening the road and TLS locking it). Only then do you knock and have a conversation — "got any coffee?" / "sure, here" (that's the HTTP request and response). You can't have the conversation before you've arrived, and you can't arrive before you know the address. The order isn't optional; it's the physics of the trip.

Why does this matter for an AI engineer specifically? Because every LLM call, every API call, every pip install is exactly this same four-step trip, just hidden behind one tidy function. When client.messages.create(...) hangs or throws, it failed at one of these four boxes — and knowing which one ("is it DNS? is the TLS cert expired? did the server 500?") is the difference between a five-minute fix and an afternoon of flailing. The common beginner mistake is treating the whole chain as a black box and blaming "the API" — when 90% of the time the trace points at something specific and boring, like a wrong hostname (DNS), a missing timeout (the pipe never opened), or an expired token (an HTTP 401 the server sent back on purpose). Learn to read the chain and you stop guessing.

Type example.com → the browser resolves DNS to an IP, opens a TCP connection, negotiates TLS (for https), sends an HTTP request, and gets a response (status + headers + body). That round trip is the whole web.

2 · HTTP methods & status codes essential

A war story you'll eventually live. Someone writes a script that submits an order with a POST. The network hiccups, the script doesn't hear back, so — being helpful — it retries. The server actually received both requests. The customer gets charged twice. That entire bug is one missing piece of knowledge: POST is not idempotent. If HTTP methods feel like trivia to memorize, this is why they aren't — the "idempotent?" column below is the exact thing that decides whether your retry logic is safe or a foot-gun.

Start with the plain-English picture. An HTTP method (also called a verb) is you telling the server what kind of thing you want to do, and a status code is the server's three-digit reply telling you how it went. That's the whole conversation: you send a verb + a URL, it sends back a number + some data. Think of a librarian: "GET me that book" (read), "PUT this book back exactly here" (replace), "DELETE this book" (remove). And the librarian always answers with a coded reply — a thumbs-up, "we don't have that", "you're not allowed", or "sorry, the shelf collapsed".

The single most useful idea in the whole section is idempotent, and it sounds scarier than it is. Idempotent just means doing it twice is the same as doing it once — like a light switch labelled "off": flip it off, flip it off again, the room's still just off. GET, PUT, and DELETE are idempotent (reading a page twice, or deleting an already-deleted record, changes nothing extra), so they're safe to retry. POST ("create a new thing") is not — retry it and you may create two things. That's why the retry code later in this chapter only auto-retries the safe verbs.

Now the status codes, and here's the trick that saves you from memorizing all of them: the first digit tells the whole story. 2xx = "great, it worked." 3xx = "it moved, look over there." 4xx = "you messed up" (bad request, not logged in, not allowed, doesn't exist). 5xx = "the server messed up." The mistake to avoid is lumping 4xx and 5xx together as "an error" and retrying both — a 4xx is your bug (retrying sends the same broken request and fails identically), while a 5xx is often transient (the server was briefly overloaded; retrying may well succeed). One digit tells you whether to fix your code or just wait and try again. Keep the two reference tables below close — you'll consult them constantly for the rest of your career.

3 · JSON — how data travels essential

Picture two people who don't speak the same language trying to hand each other a filled-in form. Your Python program thinks in dicts and lists; the server across the world might be written in Go or Rust or JavaScript and thinks in its own structures. They need a neutral, agreed-upon paper form that both sides can read and write — plain text, unambiguous, no surprises. That agreed form is JSON, and it's why an API written in any language can talk to your Python in any other. It is, quite literally, the shared handwriting of the entire web.

Concretely, JSON (JavaScript Object Notation) is just text that describes structured data using a tiny, strict vocabulary: objects in {curly braces} (which become Python dicts), arrays in [square brackets] (Python lists), plus strings, numbers, true/false, and null. That's the entire language — you can learn it in five minutes, which is exactly the point. Because it's just text, it can travel down a network pipe; because it's structured, your program can turn it back into real values it can work with. The two verbs you'll use forever are parse (text → Python values, json.loads) and serialize (Python values → text, json.dumps) — "loads" for load-from-string, "dumps" for dump-to-string.

The mistake that bites everyone at least once: confusing the JSON text with the Python object. A response body arrives as a string that looks like a dict — '{"user": "ava"}' — and beginners try to do body["user"] on it and get a baffling error, because you can't index a string by a key. You must json.loads() it first to get the real dict. The reverse trap is just as common: JSON only knows that handful of types, so a Python datetime, set, or tuple can't be serialized as-is (dumps raises a TypeError on the datetime, and silently turns your tuple into a list). The fix is to convert those to JSON-native types — a date to its isoformat() string — before sending. Get the parse/serialize direction straight in your head and a whole category of API bugs simply never happens.

JSON is the API lingua franca. Python's json maps it to dicts/lists and back.

json_demo.pyimport json
data = json.loads('{"user":"ava","roles":["dev","admin"],"active":true,"age":30}')
print(data["roles"][0], "| active:", data["active"], "| type:", type(data["active"]).__name__)
print(json.dumps({"ok": True, "items": [1, 2]}, indent=2))

dev | active: True | type: bool
{
  "ok": true,
  "items": [
    1,
    2
  ]
}

4 · Make a real request intermediate

Up to now the web has been theory — a diagram, some tables, a format. This is the moment it becomes real: you're going to make an actual program reach across the internet, touch a server, and bring something back. And here's the reassuring part — after all that build-up about DNS, TCP, TLS, and HTTP, the code to do it is two lines. The requests library folds that entire four-step trip from section 1 behind a single friendly function call. That collapse — from "understand the whole stack" to "call one function" — is the whole reason libraries exist.

The mental model to carry: requests is a very thin, very polite wrapper around the exact request/response conversation you already learned. requests.get(url) means "do a GET" (fetch/read), requests.post(url, json=...) means "do a POST" (send/create). What comes back is a response object with everything the server said, sliced into convenient pieces: r.status_code is that three-digit reply from section 2, r.json() parses the JSON body from section 3 into a Python dict, and there are headers, cookies, and the raw text if you want them. It's not doing anything mysterious — it's the same trip, with the tedious parts handled for you. This is literally what the Anthropic and AWS SDKs do internally; peel back client.messages.create(...) and you find a requests-style POST with an auth header and a JSON body.

The one habit to build from your very first real call: always pass a timeout. It's the single most common production foot-gun in this whole chapter, and it's invisible in testing. Without a timeout, if the server accepts your connection but then never answers — not an error, just silence — your program waits forever. Not thirty seconds; forever. One hung upstream service and your whole app freezes with no error to debug. timeout=10 says "if there's no answer in ten seconds, give up and raise" — turning a silent hang into a catchable exception you can retry or report. New engineers skip it because everything works on their fast local network; the omission only surfaces at 3am under real load. Add the timeout every single time, even in throwaway scripts, until it's muscle memory. The lab below is the one block in this chapter that actually hits the network — run it where you have internet.

The requests library makes HTTP trivial — this is what the LLM/AWS SDKs do under the hood. This one block hits the network.

live_request.pyimport requests
# NOTE: makes real network calls — run where you have internet.
r = requests.get("https://httpbin.org/get", params={"q": "hello"}, timeout=10)
print("status:", r.status_code, "| args:", r.json()["args"])
r = requests.post("https://httpbin.org/post", json={"name": "Ava"}, timeout=10)
print("server saw:", r.json()["json"])

status: 200 | args: {'q': 'hello'}
server saw: {'name': 'Ava'}

5 · Status-handling logic intermediate

Here's the bug that hides in almost every first-draft API script. Someone calls an endpoint, immediately does r.json()["result"], and it works great — until the day the server returns a 404 or a 500. Now the body isn't the data you expected, it's an error page or empty, and your code explodes with a cryptic KeyError three functions away from the actual problem. The root cause is skipping a step: they used the response before checking whether it succeeded. Status-handling is that missing step, and it's what separates a script that works in the demo from a client that survives contact with reality.

The plain idea: a response is a reply, and not every reply is a yes. Before you trust the body, you look at the status code and decide, per code, what it means for you. Think of checking your mail: a normal letter you open and read (200 — use the data); "no such address, returned to sender" isn't a catastrophe, it just means the thing you asked for isn't there (404 — often a perfectly normal "not found", not a crash); "mailbox full, try later" is a temporary hint to slow down and come back (429 — back off and retry); but a letter that says "the post office is on fire" is a genuine emergency you want to hear about loudly (unexpected 5xx — raise an error). Same envelope, four very different reactions.

The subtle skill — and the thing interviewers probe — is that "error" is not one bucket. The trap is writing if r.status_code != 200: raise, which treats a routine "not found" as a disaster and crashes on codes that are actually fine (like a 201 Created). A good handler branches deliberately: some non-200 codes are expected outcomes you translate into normal values (404 → None), some are signals you act on (429 → retry), and only the genuinely-unexpected ones should raise and interrupt the program. Notice too that this logic is pure — it takes a response and returns a decision, touching no network — which is exactly why the lab can prove it with a fake Resp object offline. That separation (network on one side, decision logic on the other) is a pattern you'll reuse in every testable client you build later in this chapter.

Branch on the status: 200 use it, 404 is a normal "not found", unexpected 4xx/5xx raise. Here's that logic as a pure function — offline-runnable and exactly what you wrap around a response.

status.pyclass Resp:                       # stand-in for requests.Response
    def __init__(self, status, data=None): self.status_code, self._d = status, data
    def json(self): return self._d
    def raise_for_status(self):
        if self.status_code >= 400: raise RuntimeError(f"HTTP {self.status_code}")

def handle(r):
    if r.status_code == 200: return r.json()
    if r.status_code == 404: return None          # normal outcome
    if r.status_code == 429: return "RATE_LIMITED" # back off + retry
    r.raise_for_status()                           # unexpected -> raise

print("200 ->", handle(Resp(200, {"ok": True})))
print("404 ->", handle(Resp(404)))
print("429 ->", handle(Resp(429)))
try: handle(Resp(500))
except RuntimeError as e: print("500 ->", e)

200 -> {'ok': True}
404 -> None
429 -> RATE_LIMITED
500 -> HTTP 500

6 · Advanced — retries with exponential backoff advanced

Try this the next time a webpage fails to load: hit refresh. It usually just works the second time. You've been doing manual retries your whole life without naming it — and that instinct is correct, because a huge fraction of network failures are transient: a packet dropped, a server was busy for 50 milliseconds, a connection blipped. The thing failed for no lasting reason, and simply asking again succeeds. Production clients automate exactly that refresh-and-try-again instinct. The catch is that doing it naively — retrying instantly, forever, on everything — turns a small blip into a self-inflicted outage. This section is about retrying well.

The core technique has a name that sounds fancier than it is: exponential backoff. Instead of retrying at a fixed pace, you wait a little, then double the wait each time — 0.01s, then 0.02s, then 0.04s, and so on. The reason is human, almost polite: if a server is struggling, the worst thing a thousand clients can do is all hammer it again the same instant it's trying to recover — you'd knock it right back down. Backing off exponentially gives the server breathing room that grows as the trouble persists. It's the difference between a crowd calmly filing back into a building versus everyone stampeding the door at once the moment it reopens.

Two refinements turn a decent retry loop into a production one. First, jitter — a small random amount added to each delay. Without it, a fleet of clients that all failed at the same moment will also all retry at the same moment (and again, and again) — a synchronized "thundering herd" that DDoSes your own server in perfect lockstep. Jitter smears those retries across time so they don't resonate. Second, and this is the one people get wrong: only retry what's actually retryable. Timeouts, connection errors, 5xx, and 429 are worth retrying — they're transient or the server explicitly asked you to wait. A 4xx like 400 Bad Request is not: your request itself is malformed, so retrying it identically just fails identically, wasting time and load. And always cap the attempts — a retry loop with no ceiling doesn't add resilience, it adds a hang. Retryable errors only, growing delays, jitter, a hard limit: that's the whole recipe, and it's the resiliency habit first met in py4.

Networks fail transiently. Production clients retry with exponential backoff (and jitter), cap attempts, and only retry retryable errors (timeouts, 5xx, 429 — not a 400). The resiliency habit from py4.

retry.pydef with_retry(fn, tries=4, base=0.01):
    for attempt in range(tries):
        try:
            return fn()
        except (TimeoutError, ConnectionError) as e:
            if attempt == tries - 1: raise
            delay = base * (2 ** attempt)          # 0.01, 0.02, 0.04 (+ jitter in prod)
            print(f"  attempt {attempt+1} failed ({e}); backing off {delay:.3f}s")

calls = {"n": 0}
def flaky():
    calls["n"] += 1
    if calls["n"] < 3: raise ConnectionError("transient")
    return "ok"

print("result:", with_retry(flaky), "after", calls["n"], "attempts")

  attempt 1 failed (transient); backing off 0.010s
  attempt 2 failed (transient); backing off 0.020s
result: ok after 3 attempts

7 · Advanced — rate limiting & pagination advanced

Two of the most common ways a working script quietly goes wrong in production aren't crashes — they're worse, because they're silent. The first: you loop over an API a bit too eagerly, and suddenly every call comes back 429 and your integration is throttled or banned for an hour. The second, sneakier one: you fetch "all the users", get back a tidy list of 100, ship it — and never realize the account actually has 4,000 users and you only ever saw the first page. No error, no crash, just wrong, incomplete data flowing downstream. Both come from the same blind spot: assuming an API will hand you everything, as fast as you ask. Real APIs don't work that way, and this section is about the two guardrails they use.

Rate limiting is the API saying "you're going too fast, slow down." Think of a theme-park ride that lets a fixed number of people on per minute — get greedy and you're waved off to wait. The server signals this with a 429 Too Many Requests status, and often includes a Retry-After header that literally tells you how many seconds to wait before trying again. The polite, correct move is to listen: when you see a 429, back off (this is exactly where the backoff logic from section 6 plugs in) and, if Retry-After is present, honour it precisely rather than guessing. The mistake is treating 429 as a hard failure and either crashing or — far worse — immediately retrying in a tight loop, which is how you turn a brief throttle into a ban.

Pagination is the flip side: the API refusing to hand you a firehose. Asking for "all 50,000 orders" in one response would be enormous and slow, so servers hand results back in pages — a chunk of items plus a pointer (a next cursor or page number) to where the following chunk lives. It's a book: you read a page, and the page number tells you where to go next; when there's no next page, you're done. The way you consume it is a small loop — fetch a page, collect its items, follow its next pointer, repeat until next is empty. The classic bug is writing that loop with a hard-coded number of pages ("just grab the first 5") or forgetting the loop entirely and reading only page one — both give you a plausible-looking but partial answer that passes every quick test and fails on real accounts. The fix is to always drive the loop off the cursor the server gives you, never off an assumption about how much data exists. Handle both of these and your client is honest: it takes only what it's allowed, and it takes all of what's there.

Two realities of real APIs: they rate-limit you (respect 429 + Retry-After), and they paginate large results (follow next cursors/pages). Handle both or you'll get partial data and bans.

pagination.py# A fake paginated endpoint: 3 pages of results.
PAGES = {
    None:   {"items": [1, 2], "next": "p2"},
    "p2":   {"items": [3, 4], "next": "p3"},
    "p3":   {"items": [5],    "next": None},
}
def fetch_page(cursor): return PAGES[cursor]

def fetch_all():
    items, cursor = [], None
    while True:
        page = fetch_page(cursor)
        items += page["items"]
        cursor = page["next"]
        if cursor is None: break
    return items

print("all items across pages:", fetch_all())

all items across pages: [1, 2, 3, 4, 5]

8 · Professional — a reusable client class professional

Imagine a codebase where fifteen different files each call the same API directly. One passes a 5-second timeout, another passes none. One remembers the auth header, another forgot it and only fails for admin users. One has retry logic, thirteen don't. Then the API's base URL changes — and now you're grep-ing through the whole repo, praying you catch every spot. This isn't a hypothetical; it's the natural end state of "just call requests.get wherever you need data." The reusable client class exists to kill this entire failure mode by giving every call one door to go through.

The idea is simple and you already use it daily: a client class is like the contacts app on your phone. You don't re-dial the full international number, remember the country code, and re-enter it every time you call your bank — you save it once, then just tap "Bank". A client class saves the settings for talking to one API in exactly that way: the base URL, the auth token, the default timeout, the error handling — configured once in __init__, then every method (get, post, …) just says "the thing at /users/1" and inherits all of it automatically. Change the timeout policy? One line, one place, everyone benefits. This is the Single-Responsibility idea from SD3 made concrete: one class owns "how we talk to this service," and nothing else needs to know the details. It's also exactly how the real Anthropic and AWS SDKs are shaped — an object you configure once and call many times.

The one technique that makes this class professional rather than merely tidy is dependency injection — a heavy name for a light idea: pass the network session in from outside instead of creating it inside the class. Why does that matter so much? Because the network is the one part you can't control or predict in a test — it's slow, it's flaky, it needs real credentials. If your client builds its own session internally, you can only test it by actually hitting the internet, which makes tests slow, brittle, and unrunnable in CI. But if the session is injected, your test can hand the client a fake session that returns canned responses instantly and offline — and now you can prove the client's real logic (URL building, auth headers, error handling, retries, pagination) with zero network. The seam where you swap real-for-fake is called the "network boundary," and putting a swappable joint there is what makes the whole thing testable. The beginner instinct — "just import requests and call it inside the method" — feels simpler and quietly makes the class impossible to test properly. Inject the session, and the fake in the lab below drops in exactly where requests.Session will live in production.

Teams don't scatter requests.get everywhere — they wrap an API in a client class with base URL, auth, timeouts, and error handling in one place (SD3 SOLID), with an injectable session so it's testable without a network.

api_client.pyclass ApiClient:
    def __init__(self, base_url, token=None, timeout=10, session=None):
        self.base_url = base_url.rstrip("/"); self.timeout = timeout
        self.session = session                      # inject -> testable
        if token and session: session.headers["Authorization"] = f"Bearer {token}"
    def get(self, path, **params):
        r = self.session.get(f"{self.base_url}/{path.lstrip('/')}",
                             params=params, timeout=self.timeout)
        r.raise_for_status(); return r.json()

class FakeResp:
    status_code = 200
    def json(self): return {"user": "ava"}
    def raise_for_status(self): pass
class FakeSession:
    headers = {}
    def get(self, url, params=None, timeout=None):
        print("would GET:", url); return FakeResp()

client = ApiClient("https://api.example.com", token="secret", session=FakeSession())
print("result:", client.get("users/1"))

would GET: https://api.example.com/users/1
result: {'user': 'ava'}

9 · Tech-lead — standardize reliability tech-lead

Here's how a real outage starts, and it's almost never dramatic. Ten teams each built their own way to call services. Nine set a timeout, one didn't. A downstream service gets slow one afternoon — not down, just slow. The nine time out and shed load gracefully; the one hangs, its threads pile up waiting forever, it runs out of workers, and it takes down everything upstream of it too. A local slowdown becomes a company-wide cascade, and the post-mortem traces it to a single missing timeout= in one service written eight months ago. The lesson tech leads internalize the hard way: reliability that depends on every engineer remembering to do the right thing is not reliability — it's luck.

The previous section made one client robust. This section is about the leap from "robust in one place" to "robust by default, everywhere," and the insight is almost sociological: a standard that lives in a wiki page gets ignored; a standard baked into a shared library gets enforced automatically. Think of it like the electrical code for a building. You don't trust each electrician to remember to ground every outlet — you sell only pre-wired, code-compliant outlet boxes, so doing it right is the path of least resistance and doing it wrong takes extra effort. A tech lead ships one blessed client (or a make_session factory) with retries, timeouts, backoff, logging, and rate-limit handling already inside. Teams import it instead of hand-rolling their own, and every one of their calls inherits the whole reliability policy for free — not because they read a doc, but because the safe thing is the only thing on offer.

And notice what you actually understand now: this whole chapter has been quietly building the LLM SDK from first principles. That single client.messages.create(...) line you'll write a thousand times is this — an HTTP POST (section 2) with an auth header and a JSON body (section 3), sent over the DNS→TCP→TLS→HTTP chain (section 1), its status checked (section 5), retried with backoff on the right failures (section 6), respecting rate limits and paging (section 7), wrapped in a configured-once client (section 8), standardized across the org (this section). The SDK isn't magic; it's these nine pieces, hardened and hidden. The tech-lead move is to make sure your own integrations get the same treatment — define the reliability once, and let the whole codebase inherit it. The one subtlety a lead must get right, called out below: scope automatic retries to idempotent methods only, so a retried POST can't silently double-write (the very first foot-gun from section 2, now at organizational scale).

This IS the LLM SDK unwrapped: every client.messages.create(...) is an HTTP POST with an auth header + JSON body, status-checked, retried. A lead defines one resilient client (retries, timeouts, logging, rate-limit handling) so every integration inherits the same reliability.

def classify(code):
    klass = {1: "informational", 2: "success", 3: "redirect",
             4: "client-error", 5: "server-error"}[code // 100]
    retryable = code in (429, 500, 502, 503, 504)
    return klass, retryable

for c in (200, 301, 404, 503):
    print(c, classify(c))
# 200 ('success', False)
# 301 ('redirect', False)
# 404 ('client-error', False)   -> your bug, do not retry
# 503 ('server-error', True)    -> transient, retry with backoff

import json
from datetime import date

payload = {"user": "ada", "roles": ["admin", "dev"], "active": True, "score": 3.5}
text = json.dumps(payload)          # dict  -> JSON string (what goes on the wire)
back = json.loads(text)             # JSON string -> dict
print(back == payload)              # True: str/list/bool/float survive

# gotcha: no native tuple or datetime -- you must convert first
try:
    json.dumps({"when": date.today()})
except TypeError as e:
    print("needs conversion:", e)   # serialize as when.isoformat()

import requests

def get_json(url, timeout=5):
    try:
        r = requests.get(url, timeout=timeout)
        r.raise_for_status()          # turns 4xx/5xx into an exception
        return r.json()
    except requests.HTTPError as e:
        print("bad status:", e.response.status_code)
    except requests.RequestException as e:
        print("network error:", e)    # DNS, timeout, connection refused
    return None

data = get_json("https://httpbin.org/json")
print(data and list(data.keys()))

import random

def with_retries(call, attempts=4, base=1.0, sleep=print):
    for i in range(attempts):
        ok, result = call()
        if ok:
            return result
        if i == attempts - 1:
            raise RuntimeError(f"gave up after {attempts} attempts")
        delay = base * (2 ** i) + random.uniform(0, 0.3)  # jitter avoids thundering herd
        sleep(f"retry {i+1} in {delay:.2f}s")

# fake service: fails twice (transient), then returns 200
_calls = {"n": 0}
def flaky():
    _calls["n"] += 1
    if _calls["n"] < 3:
        return False, 503
    return True, {"data": "ok"}

print(with_retries(flaky))   # prints two backoff lines, then {'data': 'ok'}

class ApiClient:
    def __init__(self, base_url, token=None, timeout=5, transport=None):
        self.base = base_url.rstrip("/")
        self.headers = {"Accept": "application/json"}
        if token:
            self.headers["Authorization"] = f"Bearer {token}"
        self.timeout = timeout
        self.transport = transport      # callable(method,url,headers,timeout)

    def get(self, path):
        url = f"{self.base}{path}"
        status, body = self.transport("GET", url, self.headers, self.timeout)
        if status >= 400:
            raise RuntimeError(f"{status} for {url}")
        return body

# offline test double
def fake(method, url, headers, timeout):
    assert headers["Authorization"] == "Bearer t0k"
    return 200, {"id": 1, "name": "ada"}

c = ApiClient("https://api.example.com", token="t0k", transport=fake)
print(c.get("/users/1"))     # {'id': 1, 'name': 'ada'}

import requests
from requests.adapters import HTTPAdapter
try:
    from urllib3.util.retry import Retry
except ImportError:                     # very old urllib3
    from requests.packages.urllib3.util.retry import Retry

def make_session(total=3, backoff=0.5, timeout=5):
    s = requests.Session()
    retry = Retry(total=total, backoff_factor=backoff,
                  status_forcelist=(429, 500, 502, 503, 504),
                  allowed_methods=frozenset(["GET", "PUT", "DELETE"]))
    adapter = HTTPAdapter(max_retries=retry)
    s.mount("https://", adapter)
    s.mount("http://", adapter)
    s.request = _with_default_timeout(s.request, timeout)  # enforce timeout
    return s

def _with_default_timeout(fn, timeout):
    def wrapper(method, url, **kw):
        kw.setdefault("timeout", timeout)
        return fn(method, url, **kw)
    return wrapper

Knowledge check check yourself