PythonのASGI Webフレームワーク「Responder」徹底解説

Responderは、かつてPythonコミュニティで注目を集めたWebフレームワークです。特に、Python界隈で非常に有名なライブラリである requests や pipenv の作者として知られるKenneth Reitz氏によって開発が開始されたことで、多くの開発者の期待を集めました。Responderは2018年頃に登場し、そのコンセプトは、当時人気だったFlaskとFalconという二つのフレームワークの良い点を取り入れ、さらに requests ライブラリのような直感的で使いやすいAPI設計思想を持ち込むことでした。

Responderの最大の特徴の一つは、Python 3.6以降で標準となった非同期処理（async/await）をネイティブにサポートするASGI (Asynchronous Server Gateway Interface) フレームワークである点です。これは、従来のWSGI (Web Server Gateway Interface) フレームワーク（例: Flask, Djangoの一部）よりも高いパフォーマンス、特にI/Oバウンドな処理（ネットワーク通信やファイルアクセスなど）が多いアプリケーションにおいて有利であると期待されました。

基本的なアイデアとして、Responderは以下のような設計思想を持っていました。

• Flaskのようなシンプルなルーティング定義（Python 3.6+のf-stringを利用）。
• Falconのようにリクエスト(req)とレスポンス(resp)オブジェクトをビュー関数に渡し、レスポンスオブジェクトを変更して返すスタイル。
• resp.text でUnicodeテキスト、resp.content でバイト列、resp.html でHTML、resp.media でJSONやYAMLを返す直感的なレスポンス設定（Requestsライブラリの影響）。
• 大文字小文字を区別しないヘッダー辞書（Requestsライブラリから）。
• resp.status_code, req.method, req.url など、Requestsライブラリでおなじみの属性名。

ResponderはStarletteという高性能なASGIツールキットを基盤として利用しており、これにより非同期処理、WebSocketサポート、バックグラウンドタスクなどの機能を実現していました。

Responderは登場当時、以下のようなモダンで開発者フレンドリーな特徴を備えていました。

• ASGIネイティブサポート: Pythonの async/await 構文をフル活用し、非同期処理を簡単に記述できました。これにより、高いパフォーマンスが期待されました。
• シンプルなAPI: 最小限のインポート (import responder) で基本的な機能を利用でき、学習コストが低いことを目指していました。
• f-stringベースのルーティング: Python 3.6からの新機能であるf-stringを使って、直感的にルートを定義できました。（例: @api.route("/hello/{who}")）
• クラスベースビュー: 継承なしでクラスを使ってビューを整理できました。
• 変更可能なレスポンスオブジェクト: ビュー関数はレスポンスオブジェクトを受け取り、その属性を変更することでレスポンス内容を決定しました。明示的な return は不要でした。
• バックグラウンドタスク: @api.background.task デコレータを使うことで、リクエスト処理とは別にバックグラウンドで関数を実行できました。
• GraphQLサポート: GraphiQLインターフェースを統合し、GraphQL APIの開発をサポートしていました。
• OpenAPIスキーマ自動生成: APIの仕様を自動で生成する機能を持っていました。
• 静的ファイル配信とJinja2テンプレート: 追加の設定なしで静的ファイルの配信やJinja2テンプレートエンジンを利用できました。
• Gzip圧縮: レスポンスを自動的にGzip圧縮する機能が組み込まれていました。
• WSGI/ASGIアプリのマウント: 他のWSGIやASGIアプリケーションをResponderアプリケーション内にマウント（統合）することが可能でした。
• テストクライアント: requests ライブラリベースのテストクライアントが組み込まれていました。

Responderを使った最も基本的なWebアプリケーションの例を見てみましょう。以下のコードを app.py のような名前で保存します。

import responder
# Responder APIインスタンスを作成
api = responder.API()
# ルート '/' へのGETリクエストを処理するビュー関数を定義
@api.route("/")
def hello_world(req, resp): """ルートURLへのアクセス時に呼ばれる関数""" resp.text = "Hello, World!" # レスポンスのテキストを設定
# ルート '/hello/{who}' へのGETリクエストを処理
# URL内の {who} の部分が引数 who に渡される
@api.route("/hello/{who}")
def hello_to(req, resp, *, who): """名前を指定して挨拶する関数""" resp.text = f"Hello, {who}!" # f-stringを使って動的なレスポンスを生成
# ルート '/hello/{who}/json' へのGETリクエストを処理
@api.route("/hello/{who}/json")
def hello_to_json(req, resp, *, who): """JSON形式で挨拶を返す関数""" resp.media = {"hello": who} # resp.mediaに辞書を設定するとJSONで返される
if __name__ == "__main__": # 開発用サーバーを起動 # デフォルトでは http://127.0.0.1:5042 で待機 api.run() 

このファイルを保存した後、ターミナルで以下のコマンドを実行して開発サーバーを起動します。

python app.py 

サーバーが起動したら、Webブラウザや curl コマンドなどで以下のURLにアクセスしてみてください。

• http://127.0.0.1:5042/ : “Hello, World!” と表示されます。
• http://127.0.0.1:5042/hello/Guido : “Hello, Guido!” と表示されます。
• http://127.0.0.1:5042/hello/Guido/json : {"hello": "Guido"} というJSONが表示されます。

このように、@api.route() デコレータを使ってURLパスとビュー関数を結びつけ、ビュー関数内で resp オブジェクトに必要な情報を設定するだけで、簡単にWeb APIやページを作成できました。

Responderのルーティングは直感的で、Flaskに似たデコレータベースの方法を採用していました。Python 3.6で導入されたf-string構文を活用している点が特徴です。

import responder
api = responder.API()
# 基本的なルート
@api.route("/home")
def home(req, resp): resp.text = "Welcome Home!"
# パスパラメータ付きルート
# URL中の {username} が関数の引数 username に渡される
@api.route("/users/{username}")
def greet_user(req, resp, *, username): resp.text = f"Hello, {username}!"
# パスパラメータに型ヒントを指定
# {user_id} が整数であることを期待し、整数に変換される
# 文字列などが渡された場合は 404 Not Found になる
@api.route("/users/{user_id:int}")
def get_user_by_id(req, resp, *, user_id): # user_id は整数型になっている resp.media = {"user_id": user_id, "name": f"User {user_id}"}
# クラスベースビュー
@api.route("/items/{item_id}")
class ItemResource: # GETリクエストを処理 def on_get(self, req, resp, *, item_id): resp.media = {"item_id": item_id, "description": "An item"} # POSTリクエストを処理 async def on_post(self, req, resp, *, item_id): # リクエストボディをJSONとして非同期に読み取る data = await req.media() resp.media = {"item_id": item_id, "received_data": data} resp.status_code = api.status_codes.HTTP_201 # ステータスコードを 201 Created に設定
# ルートの追加 (デコレータを使わない方法)
def about_page(req, resp): resp.html = "<h1>About Us</h1>"
api.add_route("/about", about_page)
if __name__ == "__main__": api.run() 

主なポイントは以下の通りです。

• @api.route("URLパス") デコレータで関数やクラスをルートに紐付けます。
• URLパス中の {パラメータ名} でパスパラメータを定義できます。これは関数のキーワード引数として渡されます (*, パラメータ名 のように指定)。
• {パラメータ名:型} のように型ヒントを指定できます (例: :int, :str, :uuid など)。型が一致しないリクエストは 404 Not Found となります。
• クラスをルートに紐付けると、HTTPメソッド名に対応するメソッド（例: on_get, on_post, on_put など）がリクエストを処理します。非同期処理が必要な場合はメソッドを async def で定義します。
• api.add_route() メソッドを使ってデコレータなしでルートを追加することも可能です。

Responderのビュー関数は、必ずリクエストオブジェクト (req) とレスポンスオブジェクト (resp) を引数として受け取ります。これらのオブジェクトを通じて、クライアントからの情報にアクセスしたり、クライアントへ返す内容を決定したりします。この設計は、requests ライブラリのAPIに影響を受けており、直感的で使いやすいことを目指していました。

リクエストオブジェクト (req)

クライアントからのHTTPリクエストに関する情報が含まれています。主な属性やメソッドは以下の通りです。

• req.method: HTTPメソッド (例: “GET”, “POST”)。
• req.url: リクエストされたURLの完全な文字列。
• req.headers: リクエストヘッダーを含む辞書ライクなオブジェクト。キーは大文字小文字を区別しません (Requestsライブラリと同様)。例: req.headers['Content-Type']。
• req.params: URLのクエリパラメータを含む辞書ライクなオブジェクト。例: /search?q=python の場合、req.params['q'] は “python” になります。
• req.content: リクエストボディをバイト列として非同期に読み取るメソッド (await req.content)。
• req.text: リクエストボディをテキストとして非同期に読み取るメソッド (await req.text)。
• req.media(): リクエストボディをJSONやYAML、フォームデータとして解析し、Pythonオブジェクト（通常は辞書）として非同期に返すメソッド (await req.media())。Content-Typeヘッダーに基づいて自動的に解析します。
• req.form(): リクエストボディをフォームデータとして解析し、辞書ライクなオブジェクトとして非同期に返すメソッド (await req.form())。req.media(format='form') のショートカットです。
• req.cookies: リクエストに含まれるクッキーを辞書形式で取得します。

import responder
api = responder.API()
@api.route("/info")
async def request_info(req, resp): info = { "method": req.method, "url": str(req.url), "headers": dict(req.headers), "query_params": dict(req.params), "cookies": dict(req.cookies), } # POST や PUT の場合はボディも読み取る if req.method in ("POST", "PUT", "PATCH"): try: # JSON か Form Data を想定 body_data = await req.media() info["body_data"] = body_data except Exception as e: info["body_error"] = str(e) resp.media = info
if __name__ == "__main__": api.run() 

レスポンスオブジェクト (resp)

クライアントに返すHTTPレスポンスの内容を設定するために使用します。ビュー関数はこのオブジェクトの属性を変更し、関数自体は何も返す必要はありません（return文は不要）。

• resp.status_code: HTTPステータスコードを設定します。デフォルトは 200 OK です。 api.status_codes を使って定数で指定できます（例: api.status_codes.HTTP_404_NOT_FOUND）。
• resp.headers: レスポンスヘッダーを設定するための辞書ライクなオブジェクト。例: resp.headers['Content-Type'] = 'application/xml'。
• resp.content: レスポンスボディをバイト列で設定します。
• resp.text: レスポンスボディをUnicodeテキストで設定します。Content-Typeは text/plain; charset=utf-8 になります。
• resp.html: レスポンスボディをHTMLテキストで設定します。Content-Typeは text/html; charset=utf-8 になります。
• resp.media: レスポンスボディをPythonオブジェクト（通常は辞書やリスト）で設定します。Content-Typeに応じて自動的にJSONまたはYAMLにシリアライズされます（デフォルトはJSON）。
• resp.cookies: レスポンスにクッキーを設定するための属性。
• resp.set_cookie(key, value, ...): クッキーを設定するメソッド。有効期限などのオプションも指定可能です。
• resp.delete_cookie(key): クッキーを削除するためのメソッド。

import responder
api = responder.API()
@api.route("/data")
def send_data(req, resp): # クエリパラメータ 'format' の値に応じてレスポンス形式を変える output_format = req.params.get("format", "json") # デフォルトはjson data = {"message": "Success!", "items": [1, 2, 3]} if output_format == "json": resp.media = data # JSONで返す elif output_format == "html": # 簡単なHTMLを生成して返す items_html = "".join(f"<li>{item}</li>" for item in data["items"]) resp.html = f"<h1>{data['message']}</h1><ul>{items_html}</ul>" elif output_format == "text": resp.text = f"Message: {data['message']}\nItems: {', '.join(map(str, data['items']))}" else: # サポート外のフォーマットの場合は 400 Bad Request を返す resp.status_code = api.status_codes.HTTP_400_BAD_REQUEST resp.media = {"error": "Unsupported format"} # カスタムヘッダーを追加 resp.headers["X-Custom-Header"] = "Responder Example" # クッキーを設定 resp.set_cookie("session_id", "abc123xyz", max_age=3600) # 1時間有効
if __name__ == "__main__": api.run() 

この req と resp を中心としたAPI設計は、特に requests ライブラリに慣れ親しんだ開発者にとっては非常に分かりやすいものでした。

Responderは、HTTPリクエストのレスポンスを返した後に実行される「バックグラウンドタスク」を簡単に定義する機能を提供していました。これは、メール送信、時間のかかる計算、外部APIへの通知など、レスポンスを返すのを待たせる必要のない処理に便利でした。

@api.background.task デコレータを関数に付与するだけで、その関数をバックグラウンドタスクとして登録できました。

import responder
import time
import asyncio # asyncio.sleep を使うため
api = responder.API()
# バックグラウンドで実行されるタスク関数
@api.background.task
def process_data(data_id, message): """時間のかかる処理をシミュレートするタスク""" print(f"バックグラウンドタスク開始: data_id={data_id}, message='{message}'") # time.sleep(5) # 同期的なsleep (CPUをブロックする可能性がある) # 非同期な待機が推奨される loop = asyncio.get_event_loop() loop.run_until_complete(asyncio.sleep(5)) # 5秒待機 (非同期) print(f"バックグラウンドタスク終了: data_id={data_id}")
@api.route("/submit/{item_id}")
async def submit_item(req, resp, *, item_id): """リクエストを受け付け、すぐにレスポンスを返し、その後バックグラウンドタスクを実行""" # リクエストからデータを取得 (例) request_data = await req.media() message = request_data.get("message", "No message") # バックグラウンドタスクを呼び出す (関数呼び出しのように見える) # この呼び出しはすぐに関数から戻り、タスクはバックグラウンドで実行される process_data(item_id, message) resp.media = {"status": "submitted", "item_id": item_id} print(f"レスポンスを返しました: item_id={item_id}")
if __name__ == "__main__": api.run() 

上記の例では、/submit/{item_id} にPOSTリクエストを送ると、サーバーはすぐに {"status": "submitted", "item_id": ...} というJSONレスポンスを返します。その後、process_data 関数がバックグラウンドで実行され、コンソールに開始と終了のメッセージが出力されます（5秒間の待機後）。

この機能は、ユーザー体験を損なわずに重い処理を行うための便利な方法を提供していました。内部的には、Starletteが提供するバックグラウンドタスク機能を利用していました。

Responderを理解する上で、ASGI (Asynchronous Server Gateway Interface) について知ることが重要です。ASGIは、PythonのWebサーバーとWebアプリケーション（またはフレームワーク）が非同期的に通信するための標準インターフェース仕様です。

従来のWSGI (Web Server Gateway Interface) は同期的であり、一つのリクエストに対して一つのプロセスやスレッドが処理を完了するまでブロックされるのが基本でした。これはシンプルですが、ネットワークI/O待ちなどが多いWebアプリケーションでは、リソースを効率的に使えないという課題がありました。

ASGIは、async/await を活用することで、I/O待ちの間に他のリクエストを処理できるようにし（ノンブロッキングI/O）、より少ないリソースで多くの同時接続を捌くことを可能にします。また、WebSocketやHTTP/2など、従来のWSGIでは扱いにくかったプロトコルも自然にサポートできるように設計されています。

Responderは、このASGIに完全準拠したフレームワークとして設計されました。これにより、以下のような利点がありました。

• 高パフォーマンス: 特に同時接続数が多い場合や、I/O処理がボトルネックになる場合に、WSGIフレームワークよりも高い性能を発揮する可能性がありました。
• 非同期処理の容易さ: async def でビュー関数を定義するだけで、フレームワークが適切に非同期処理を扱ってくれました。
• モダンなプロトコルのサポート: ASGIの恩恵により、WebSocketなどの機能を比較的簡単に実装できました。

Responderは内部でStarletteという軽量かつ高性能なASGIツールキットを利用していました。StarletteはASGIの基本的な機能（ルーティング、リクエスト/レスポンス処理、WebSocket、バックグラウンドタスクなど）を提供し、Responderはそれに加えて、より高レベルな機能（requests ライクなAPI、自動スキーマ生成、Jinja2統合など）を提供していました。

Responderの登場は、PythonのWeb開発における非同期処理の普及とASGI標準の採用が進む時期と重なり、次世代のフレームワークとして大きな期待を集めました。

Responderは2018年後半に登場し、そのコンセプトと著名な開発者により大きな注目を集めましたが、残念ながら開発は比較的早い段階で停滞してしまったようです。2019年や2020年の時点でも、将来性に対する懸念の声が上がっていました。GitHubリポジトリも、現在は作者のアーカイブ用アカウント (kennethreitz-archive) に移動されているか、あるいは作者自身のメインリポジトリリストからも外れているように見えます。

Responderが目指した多くの機能やコンセプト（ASGIネイティブ、高いパフォーマンス、型ヒントの活用、自動ドキュメント生成など）は、その後に登場または発展した他のフレームワークに引き継がれ、より洗練された形で実現されています。

主な代替 ASGI フレームワーク

現在、PythonでASGIベースのWebアプリケーションを開発する場合、以下のようなフレームワークが有力な選択肢となります。

これらのフレームワークは、Responderが目指した目標の多くを達成し、さらに発展させています。特にFastAPIは、Responderと同様にStarletteをベースとしつつ、Pydanticによる強力な型システムとデータバリデーション、自動APIドキュメント生成機能を提供し、現在のPython API開発において非常に人気が高まっています。

Responderは、PythonのWebフレームワークの世界にASGIという新しい波が訪れた時期に、requests ライブラリのような親しみやすいAPIとモダンな機能（非同期処理、GraphQL、自動スキーマ生成など）を統合しようとした意欲的なプロジェクトでした。その登場は多くの開発者に期待を抱かせましたが、残念ながら開発は継続されず、現在ではアクティブなプロジェクトではありません。

しかし、Responderが示した方向性やアイデアは、FastAPIをはじめとする後続のフレームワークに大きな影響を与えたと言えるでしょう。特に、開発者体験（DX）を重視したAPI設計や、ASGIの可能性を追求する姿勢は、現代のPython Web開発の潮流の一部となっています。

Responderについて学ぶことは、Python Webフレームワークの進化の歴史や、ASGIの重要性を理解する上で興味深いですが、これから新しいプロジェクトを始める際には、FastAPI、Starlette、Django (v3+)、Sanicといった、現在も活発に開発・メンテナンスされているフレームワークを選択することが強く推奨されます。 これらはより成熟しており、豊富なドキュメント、活発なコミュニティ、そして長期的なサポートが期待できます。

Responderは短い期間でしたが、Python Web開発の未来に向けた一つのビジョンを示したフレームワークとして記憶されるでしょう。