Hvordan fungerer request-livssyklusen i Django?

Question

IT Interview Practice · Accepted Answer

I Django håndteres en request av **WSGI/ASGI-handleren**, pakkes inn av en stack med **middleware**, rutes av **URL-resolveren** til en **view**, og gjøres om til et `HttpResponse` som flyter tilbake ut gjennom den samme middlewaren i motsatt rekkefølge.

## Stegene

```
Webserver ──▶ WSGI/ASGI-handler  (lager HttpRequest)
   ▼
Middleware — request-fase          (topp → bunn: __call__ før get_response)
   ▼
URL-resolver (urls.py)  ── match path → view + kwargs
   ▼
Middleware — process_view-hook
   ▼
View (funksjon / class-based)  ── logikken din, returnerer HttpResponse
   ▼
Middleware — response-fase          (bunn → topp: etter get_response)
   ▼
HttpResponse ──▶ klient
```

1. **Handler** — WSGI (synkron) eller ASGI (async) handleren bygger et `HttpRequest` fra environ/scope.
2. **Middleware, request-fase** — hver middlewares kode *før* `get_response()` kjører fra topp til bunn (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Hvilken som helst av dem kan kortslutte og returnere en respons tidlig.
3. **URL-oppløsning** — `ROOT_URLCONF`-mønstrene matches mot pathen for å velge en view og fange kwargs.
4. **`process_view`** — en middleware-hook som kjører rett før viewet blir kalt.
5. **View** — din funksjons- eller class-based view kjører, spør typisk mot modeller og rendrer en template, og returnerer et `HttpResponse`. Exceptions utløser `process_exception`.
6. **Middleware, response-fase** — kode *etter* `get_response()` kjører fra bunn til topp, som lar middleware endre den utgående responsen (headere, komprimering).
7. `HttpResponse` streames tilbake til serveren og klienten.

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

def __call__(self, request):          # 2. request-fase (før)
        request.started = time.monotonic()
        response = self.get_response(request)  # kaller neste lag / view
        response["X-Time"] = "..."         # 6. response-fase (etter)
        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)})
```

## Hvorfor det er viktig

Djangos request/response-syklus er middleware-sentrisk, så det meste av tverrgående oppførsel — auth, sessions, CSRF, security-headere, caching — er implementert som ordnet middleware. Å forstå at request-fase-kode kjører ovenfra og ned og response-fase-kode kjører nedenfra og opp (og at rekkefølgen i `MIDDLEWARE` betyr noe) er avgjørende for å plassere din egen middleware riktig, feilsøke hvorfor en `403`/redirect skjer før viewet ditt, og vite hvor du skal koble inn logikk uten å måtte røre hvert eneste view.

Stegene

Hvorfor det er viktig

Relaterte spørsmål