Wie funktioniert der Request-Lebenszyklus in Django?

Question

IT Interview Practice · Accepted Answer

In Django wird ein Request vom **WSGI/ASGI-Handler** verarbeitet, von einem Stapel aus **Middleware** umhüllt, vom **URL-Resolver** an ein **View** geroutet und in eine `HttpResponse` verwandelt, die durch dieselbe Middleware in umgekehrter Reihenfolge wieder nach außen fließt.

## Die Phasen

```
Web server ──▶ WSGI/ASGI handler  (erstellt HttpRequest)
   ▼
Middleware — Request-Phase        (oben → unten: __call__ vor get_response)
   ▼
URL resolver (urls.py)  ── matche path → view + kwargs
   ▼
Middleware — process_view-Hook
   ▼
View (function / class-based)  ── deine Logik, gibt HttpResponse zurück
   ▼
Middleware — Response-Phase        (unten → oben: nach get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — der WSGI- (sync) oder ASGI- (async) Handler baut aus environ/scope eine `HttpRequest`.
2. **Middleware, Request-Phase** — der Code jeder Middleware *vor* `get_response()` läuft von oben nach unten (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Jede davon kann abkürzen und frühzeitig eine Response zurückgeben.
3. **URL-Auflösung** — `ROOT_URLCONF`-Muster werden gegen den Pfad gematcht, um ein View auszuwählen und kwargs zu erfassen.
4. **`process_view`** — ein Middleware-Hook, der unmittelbar vor dem Aufruf des Views läuft.
5. **View** — dein funktions- oder klassenbasiertes View läuft, fragt typischerweise Models ab und rendert ein Template, und gibt eine `HttpResponse` zurück. Ausnahmen lösen `process_exception` aus.
6. **Middleware, Response-Phase** — Code *nach* `get_response()` läuft von unten nach oben und lässt Middleware die ausgehende Response verändern (Header, Kompression).
7. Die `HttpResponse` wird zurück an Server und Client gestreamt.

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

def __call__(self, request):          # 2. Request-Phase (vor)
        request.started = time.monotonic()
        response = self.get_response(request)  # ruft die nächste Schicht / das View auf
        response["X-Time"] = "..."         # 6. Response-Phase (nach)
        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)})
```

## Warum es wichtig ist

Djangos Request/Response-Zyklus ist middleware-zentriert, daher wird das meiste übergreifende Verhalten — Auth, Sessions, CSRF, Security-Header, Caching — als geordnete Middleware implementiert. Zu verstehen, dass Code der Request-Phase von oben nach unten und Code der Response-Phase von unten nach oben läuft (und dass die Reihenfolge in `MIDDLEWARE` wichtig ist), ist essenziell, um deine eigene Middleware richtig zu platzieren, zu debuggen, warum ein `403`/Redirect vor deinem View passiert, und zu wissen, wo du Logik einhängst, ohne jedes View anfassen zu müssen.

Die Phasen

Warum es wichtig ist

Ähnliche Fragen