Django ではリクエストのライフサイクルはどのように動作しますか？

Question

IT Interview Practice · Accepted Answer

Django では、リクエストは **WSGI/ASGI handler** によって処理され、**middleware** のスタックにラップされ、**URL resolver** によって **view** へルーティングされ、`HttpResponse` に変換されて、同じ middleware を逆順に通って外へと流れ戻ります。

## ステージ

```
Web server ──▶ WSGI/ASGI handler  (HttpRequest を生成)
   ▼
Middleware — request フェーズ        (上 → 下: get_response の前の __call__)
   ▼
URL resolver (urls.py)  ── path をマッチ → view + kwargs
   ▼
Middleware — process_view フック
   ▼
View (function / class-based)  ── あなたのロジック, HttpResponse を返す
   ▼
Middleware — response フェーズ       (下 → 上: get_response の後)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI（同期）または ASGI（非同期）handler が environ/scope から `HttpRequest` を構築します。
2. **Middleware, request フェーズ** — 各 middleware の `get_response()` の*前*のコードが上から下へ実行されます（`SecurityMiddleware`、`SessionMiddleware`、`AuthenticationMiddleware`、CSRF、…）。いずれもショートサーキットして早期に response を返すことができます。
3. **URL 解決** — `ROOT_URLCONF` のパターンが path に対してマッチされ、view を選択して kwargs を捕捉します。
4. **`process_view`** — view が呼び出される直前に実行される middleware フックです。
5. **View** — 関数ベースまたはクラスベースの view が実行され、通常はモデルをクエリしてテンプレートをレンダリングし、`HttpResponse` を返します。例外は `process_exception` をトリガーします。
6. **Middleware, response フェーズ** — `get_response()` の*後*のコードが下から上へ実行され、middleware が送出される response（header、圧縮）を変更できます。
7. `HttpResponse` はサーバーとクライアントへストリームで返されます。

```python
# middleware.py
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

def __call__(self, request):          # 2. request フェーズ (前)
        request.started = time.monotonic()
        response = self.get_response(request)  # 次のレイヤー / view を呼ぶ
        response["X-Time"] = "..."         # 6. response フェーズ (後)
        return response

# urls.py  → 3. routing
urlpatterns = [path("items/<int:pk>/", views.item_detail)]

# views.py → 5. view
def item_detail(request, pk):
    return render(request, "item.html", {"item": Item.objects.get(pk=pk)})
```

## なぜ重要なのか

Django のリクエスト/レスポンスサイクルは middleware 中心であり、横断的な振る舞いのほとんど — auth、session、CSRF、security header、キャッシュ — は順序付けられた middleware として実装されています。request フェーズのコードが上から下へ、response フェーズのコードが下から上へ実行される（そして `MIDDLEWARE` の順序が重要である）ことを理解するのは、自分の middleware を正しく配置し、なぜ `403`/リダイレクトが view の前に起こるのかをデバッグし、すべての view に触れずにどこにロジックをフックすべきかを知るために不可欠です。

ステージ

なぜ重要なのか

関連する質問