Requests

Requests is Python’s most-downloaded HTTP library, used to send HTTP/1.1 requests without the boilerplate that Python’s built-in urllib demands. It wraps connection pooling, redirect handling, cookie persistence, and content decoding behind a small, readable API, so a GET request with auth and query params is one line of code instead of a dozen.

Built on top of urllib3, idna, charset_normalizer, and certifi, Requests has become the de facto standard for HTTP in Python — GitHub reports it as a dependency of over four million repositories, and it anchors nearly every tutorial, SDK, and scraping script written in the language.

What You Get

• Simple verb functions (requests.get, .post, etc.) for one-off calls, and a Session object for connection pooling, persistent cookies, and shared headers/auth across many requests
• Automatic JSON encoding/decoding via the json= kwarg and Response.json(), plus multipart file uploads via files=
• Built-in Basic/Digest/custom auth handlers, TLS certificate verification (via certifi), and configurable proxy support
• Transparent redirect following, connection-level retry configuration through HTTPAdapter, and automatic content decompression/decoding
• A Response object exposing status code, headers, cookies, elapsed time, and both raw and decoded body access

Common Use Cases

• Calling third-party REST APIs from scripts, backend services, or automation tooling
• Building lightweight web scrapers and crawlers that need cookie/session persistence
• Serving as the transport layer underneath higher-level SDKs (cloud provider clients, webhook senders, CLI tools)
• Writing integration tests that hit real or mocked HTTP endpoints

Under The Hood

Architecture — Requests layers three concerns cleanly: api.py exposes the verb-shaped public functions (get, post, …) that each open a short-lived Session and delegate to it; sessions.py’s Session class owns cross-request state (cookies via a RequestsCookieJar, headers, auth, proxies) and merges per-call overrides with session defaults via merge_setting/merge_hooks; and adapters.py’s HTTPAdapter (a BaseAdapter subclass) wraps a urllib3.PoolManager to actually open sockets, handle retries, and translate low-level urllib3 exceptions into Requests’ own exception hierarchy (exceptions.py). A Request is built into an immutable PreparedRequest (models.py) before being sent, decoupling “what the user asked for” from “what goes on the wire,” which is also what lets Session.send() be called directly for advanced use.

Tech Stack — Pure Python (99%+ of the codebase), packaged with setuptools and a pyproject.toml-driven build. Runtime dependencies are minimal and deliberate: urllib3 for the actual HTTP/connection-pooling implementation, certifi for a bundled CA store, idna for internationalized domain handling, and charset_normalizer for encoding detection — Requests itself is an ergonomics layer on top of urllib3, not a from-scratch HTTP stack. Optional extras (PySocks for SOCKS proxies, chardet) are isolated behind [project.optional-dependencies] so the default install stays lean.

Code Quality — The tests/ directory contains 237+ test functions across test_requests.py plus focused suites for cookies, structures, and internal utilities, run via pytest against httpbin fixtures for realistic request/response behavior; CI-relevant lint/format is enforced with ruff (configured in pyproject.toml) and pre-commit hooks. The package ships a py.typed marker and increasingly precise type hints (_types.py, TypedDict-based kwargs like RequestKwargs), and pyright runs in strict mode over src/requests, which is unusually rigorous for a library this old and this widely depended upon.

API Design — The verb functions (requests.get(url, params=...)) are close to the ergonomic ceiling for a synchronous HTTP client: no client object to construct for a one-off call, sensible defaults (redirects on, cookies handled, JSON body auto-serialized), and a Response object where .json(), .text, .status_code, and truthiness (if response:) all behave the way a newcomer would guess. The main friction point by design is that it is fully synchronous — there is no native async/await support, which is why the httpx project exists as a spiritual successor for async workloads.