Comment fonctionne le cycle de vie d'une requête dans Django ?

Question

IT Interview Practice · Accepted Answer

Dans Django, une requête est traitée par le **handler WSGI/ASGI**, enveloppée par une pile de **middleware**, routée par l'**URL resolver** vers une **view**, et transformée en `HttpResponse` qui ressort par les mêmes middleware en sens inverse.

## Les étapes

```
Web server ──▶ WSGI/ASGI handler  (crée HttpRequest)
   ▼
Middleware — phase request        (haut → bas : __call__ avant get_response)
   ▼
URL resolver (urls.py)  ── associe path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── votre logique, retourne HttpResponse
   ▼
Middleware — phase response        (bas → haut : après get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — le handler WSGI (synchrone) ou ASGI (asynchrone) construit un `HttpRequest` à partir de l'environ/scope.
2. **Middleware, phase request** — le code de chaque middleware *avant* `get_response()` s'exécute de haut en bas (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). N'importe lequel peut court-circuiter et retourner une response de manière anticipée.
3. **URL resolution** — les patterns de `ROOT_URLCONF` sont associés au path pour sélectionner une view et capturer les kwargs.
4. **`process_view`** — un hook de middleware qui s'exécute juste avant l'appel de la view.
5. **View** — votre view sous forme de fonction ou de classe s'exécute, interroge généralement les models et rend un template, puis retourne un `HttpResponse`. Les exceptions déclenchent `process_exception`.
6. **Middleware, phase response** — le code *après* `get_response()` s'exécute de bas en haut, permettant au middleware de modifier la response sortante (headers, compression).
7. Le `HttpResponse` est renvoyé en streaming vers le server puis le client.

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

def __call__(self, request):          # 2. phase request (avant)
        request.started = time.monotonic()
        response = self.get_response(request)  # appelle la couche suivante / view
        response["X-Time"] = "..."         # 6. phase response (aprè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)})
```

## Pourquoi c'est important

Le cycle request/response de Django est centré sur le middleware, donc la plupart des comportements transversaux — auth, sessions, CSRF, security headers, caching — sont implémentés sous forme de middleware ordonnés. Comprendre que le code de la phase request s'exécute de haut en bas et que le code de la phase response s'exécute de bas en haut (et que l'ordre dans `MIDDLEWARE` compte) est essentiel pour placer correctement votre propre middleware, déboguer pourquoi un `403`/redirect survient avant votre view, et savoir où greffer la logique sans toucher à chaque view.

Les étapes

Pourquoi c'est important

Questions connexes