Como funciona o ciclo de vida de uma requisição no Django?

Question

IT Interview Practice · Accepted Answer

No Django, uma requisição é tratada pelo **WSGI/ASGI handler**, envolvida por uma pilha de **middleware**, roteada pelo **URL resolver** até uma **view** e transformada em um `HttpResponse` que flui de volta para fora pelo mesmo middleware, na ordem inversa.

## As etapas

```
Web server ──▶ WSGI/ASGI handler  (cria HttpRequest)
   ▼
Middleware — fase de request       (topo → base: __call__ antes de get_response)
   ▼
URL resolver (urls.py)  ── casa path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── sua lógica, retorna HttpResponse
   ▼
Middleware — fase de response      (base → topo: depois de get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — o handler WSGI (síncrono) ou ASGI (assíncrono) constrói um `HttpRequest` a partir do environ/scope.
2. **Middleware, fase de request** — o código de cada middleware *antes* de `get_response()` roda de cima para baixo (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Qualquer um deles pode interromper o fluxo e retornar uma resposta antecipadamente.
3. **Resolução de URL** — os padrões de `ROOT_URLCONF` são casados com a rota para selecionar uma view e capturar kwargs.
4. **`process_view`** — um hook de middleware que roda logo antes de a view ser chamada.
5. **View** — sua view baseada em função ou classe roda, normalmente consultando models e renderizando um template, e retorna um `HttpResponse`. Exceções disparam `process_exception`.
6. **Middleware, fase de response** — o código *depois* de `get_response()` roda de baixo para cima, permitindo que o middleware modifique a resposta de saída (cabeçalhos, compressão).
7. O `HttpResponse` é transmitido de volta para o servidor e o cliente.

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

def __call__(self, request):          # 2. fase de request (antes)
        request.started = time.monotonic()
        response = self.get_response(request)  # chama a próxima camada / view
        response["X-Time"] = "..."         # 6. fase de response (depois)
        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)})
```

## Por que isso importa

O ciclo de requisição/resposta do Django é centrado em middleware, então a maior parte do comportamento transversal — auth, sessões, CSRF, cabeçalhos de segurança, cache — é implementada como middleware ordenado. Entender que o código da fase de request roda de cima para baixo e o da fase de response de baixo para cima (e que a ordem em `MIDDLEWARE` importa) é essencial para posicionar seu próprio middleware corretamente, depurar por que um `403`/redirecionamento acontece antes da sua view e saber onde conectar a lógica sem tocar em cada view.

As etapas

Por que isso importa

Perguntas relacionadas