¿Cómo funciona el ciclo de vida de una petición en Django?

Question

IT Interview Practice · Accepted Answer

En Django, una petición la maneja el **handler WSGI/ASGI**, la envuelve una pila de **middleware**, el **URL resolver** la enruta a una **view**, y se convierte en un `HttpResponse` que fluye de vuelta hacia fuera a través del mismo middleware en orden inverso.

## Las etapas

```
Web server ──▶ WSGI/ASGI handler  (crea HttpRequest)
   ▼
Middleware — fase de request        (arriba → abajo: __call__ antes de get_response)
   ▼
URL resolver (urls.py)  ── coincide path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── tu lógica, devuelve HttpResponse
   ▼
Middleware — fase de response        (abajo → arriba: después de get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — el handler WSGI (sync) o ASGI (async) construye un `HttpRequest` a partir del environ/scope.
2. **Middleware, fase de request** — el código de cada middleware *antes* de `get_response()` se ejecuta de arriba abajo (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Cualquiera de ellos puede cortocircuitar y devolver una respuesta antes de tiempo.
3. **Resolución de URL** — los patrones de `ROOT_URLCONF` se hacen coincidir con la ruta para seleccionar una view y capturar kwargs.
4. **`process_view`** — un hook de middleware que se ejecuta justo antes de llamar a la view.
5. **View** — tu view basada en función o en clase se ejecuta, normalmente consultando modelos y renderizando una plantilla, y devuelve un `HttpResponse`. Las excepciones disparan `process_exception`.
6. **Middleware, fase de response** — el código *después* de `get_response()` se ejecuta de abajo arriba, permitiendo al middleware modificar la respuesta saliente (cabeceras, compresión).
7. El `HttpResponse` se transmite de vuelta al servidor y al 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)  # llama a la siguiente capa / view
        response["X-Time"] = "..."         # 6. fase de response (después)
        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 qué es importante

El ciclo request/response de Django está centrado en el middleware, por lo que la mayor parte del comportamiento transversal — auth, sesiones, CSRF, cabeceras de seguridad, caching — se implementa como middleware ordenado. Entender que el código de la fase de request se ejecuta de arriba abajo y el de la fase de response de abajo arriba (y que el orden en `MIDDLEWARE` importa) es esencial para colocar tu propio middleware correctamente, depurar por qué un `403`/redirección ocurre antes de tu view, y saber dónde enganchar lógica sin tocar cada view.

Las etapas

Por qué es importante

Preguntas relacionadas