requestsはなぜ事実上の標準になったか
🧭 はじめに（What / Why）
このページでは、PythonにおけるHTTPクライアントの代名詞とも言える requests が なぜ「事実上の標準」になったのかを理解します。
- 何がそれ以前のHTTP実装を「つらい」ものにしていたのか
- requestsは何を解決し、何をあえて解決しなかったのか
- 今日、requestsを選ぶ判断が妥当な場面はどこか
到達点は明確です。 「requestsは人間のためのHTTP APIを最初に完成させた」 ──この1点を腹落ちさせることです。
🕰 立ち位置の整理（Before / After）
Before: 標準ライブラリの現実
requests以前、PythonでHTTP通信を行う主役は urllib 系でした。
技術的には「できる」ものの、現実はこうでした。
- URLエンコード・デコードを自分で意識する必要がある
- Request / Response の責務が分かりにくい
- Cookie・Session・Header 操作が冗長
- 人間が読むコードにならない
標準ライブラリ＝使いやすいとは限らない、という典型例です。
After: requestsの登場
requestsはurllibを置き換えるために登場したのではありません。 「人間がHTTPを書く」という体験そのものを置き換えたのです。
- URLは文字列で渡すだけ
- headers / params / data がそのまま引数
- レスポンスは「読める」オブジェクト
🧠 設計思想の核（最重要）
人間向けAPIという割り切り
requestsの設計思想は一貫しています。
HTTPは機械のためのプロトコルだが、 それを扱うコードは人間のためのものである
そのために、requestsは次を優先しました。
- 明示的で直感的な引数設計
- 1行で意味が伝わるコード
- 失敗時の挙動が推測しやすいAPI
そして、次を捨てています。
- 非同期対応（当初）
- 最先端プロトコル（HTTP/2など）
- 極端な抽象化
requestsは「万能HTTPクライアント」ではなく、最も書かれるHTTPコードに最適化されています。
⚖️ できること / できないこと
できること（得意領域）
- 同期的なHTTP通信
- REST API クライアント
- スクリプト / バッチ / CLI
- 小〜中規模アプリケーション
できないこと（設計上の限界）
- 大量同時接続（高並列）
- asyncio ネイティブ環境
- HTTP/2 を前提とした設計
「非同期が必要かもしれないから」とrequestsを無理に拡張するのは事故の始まりです。
🧪 典型的な利用パターン（最小）
requestsの価値は、次の構造が一目で分かる点にあります。
import requests
response = requests.get(
"https://api.example.com/items",
params={"limit": 10},
headers={"Authorization": "Bearer TOKEN"}
)
data = response.json()
- HTTPメソッド
- URL
- クエリ
- ヘッダ
- レスポンス
すべてが視覚的に分離されています。
🚧 よくある誤解・アンチパターン
誤解①: 「とりあえずrequestsで全部いける」
- 非同期処理が必要になった瞬間に破綻
- スレッドで無理やり並列化 → デバッグ地獄
誤解②: 「requestsは古い」
- requestsは枯れている
- 枯れている = 信頼性が高い
流行りではなく、用途との適合で評価すべきライブラリです。
🔗 他ライブラリとの関係
- 非同期対応 → httpx
- asyncio特化 → aiohttp
- 高レベルAPI呼び出し → requests + pydantic
requestsは「HTTP層の最下段」を安定して担う存在です。
🧾 まとめ（1文で言うと）
requestsは「人間がHTTPを書く」という体験を完成させたライブラリである。