Hoe werkt de request-lifecycle in Django?

Question

IT Interview Practice · Accepted Answer

In Django wordt een request afgehandeld door de **WSGI/ASGI-handler**, omhuld door een stack van **middleware**, gerouteerd door de **URL-resolver** naar een **view**, en omgezet in een `HttpResponse` die er in omgekeerde volgorde weer uitstroomt door dezelfde middleware.

## De fasen

```
Webserver ──▶ WSGI/ASGI-handler  (maakt HttpRequest)
   ▼
Middleware — request-fase          (boven → onder: __call__ vóór get_response)
   ▼
URL-resolver (urls.py)  ── match pad → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (function / class-based)  ── jouw logica, geeft HttpResponse terug
   ▼
Middleware — response-fase          (onder → boven: na get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — de WSGI- (sync) of ASGI- (async) handler bouwt een `HttpRequest` op uit de environ/scope.
2. **Middleware, request-fase** — de code van elke middleware *vóór* `get_response()` draait van boven naar onder (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Elk ervan kan kortsluiten en vroegtijdig een response teruggeven.
3. **URL-resolutie** — de patronen van `ROOT_URLCONF` worden gematcht met het pad om een view te selecteren en kwargs vast te leggen.
4. **`process_view`** — een middleware-hook die vlak voor het aanroepen van de view draait.
5. **View** — jouw function- of class-based view draait, doorgaans door models te bevragen en een template te renderen, en geeft een `HttpResponse` terug. Excepties triggeren `process_exception`.
6. **Middleware, response-fase** — de code *na* `get_response()` draait van onder naar boven, waardoor middleware de uitgaande response kan aanpassen (headers, compressie).
7. De `HttpResponse` wordt teruggestreamd naar de server en client.

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

def __call__(self, request):          # 2. request-fase (ervoor)
        request.started = time.monotonic()
        response = self.get_response(request)  # roept de volgende laag / view aan
        response["X-Time"] = "..."         # 6. response-fase (erna)
        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)})
```

## Waarom het belangrijk is

De request/response-cyclus van Django is middleware-centrisch, dus het meeste cross-cutting gedrag — auth, sessies, CSRF, security headers, caching — wordt geïmplementeerd als geordende middleware. Begrijpen dat request-fase-code van boven naar onder draait en response-fase-code van onder naar boven (en dat de volgorde in `MIDDLEWARE` uitmaakt) is essentieel om je eigen middleware correct te plaatsen, te debuggen waarom een `403`/redirect gebeurt vóór jouw view, en te weten waar je logica kunt inhaken zonder elke view aan te raken.

De fasen

Waarom het belangrijk is

Gerelateerde vragen