Hur fungerar request-livscykeln i Django?

Question

IT Interview Practice · Accepted Answer

I Django hanteras en request av **WSGI/ASGI-handlern**, omsluts av en stack av **middleware**, dirigeras av **URL-resolvern** till en **view**, och omvandlas till ett `HttpResponse` som flödar tillbaka ut genom samma middleware i omvänd ordning.

## Stegen

```
Web server ──▶ WSGI/ASGI handler  (skapar HttpRequest)
   ▼
Middleware — request-fas        (topp → botten: __call__ före get_response)
   ▼
URL resolver (urls.py)  ── matcha path → view + kwargs
   ▼
Middleware — process_view-hook
   ▼
View (function / class-based)  ── din logik, returnerar HttpResponse
   ▼
Middleware — response-fas        (botten → topp: efter get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI-handlern (synkron) eller ASGI-handlern (asynkron) bygger ett `HttpRequest` från environ/scope.
2. **Middleware, request-fas** — varje middlewares kod *före* `get_response()` körs uppifrån-och-ned (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Vilken som helst av dem kan kortsluta och returnera en response tidigt.
3. **URL-resolution** — `ROOT_URLCONF`-mönster matchas mot path för att välja en view och fånga kwargs.
4. **`process_view`** — en middleware-hook som körs precis innan viewn anropas.
5. **View** — din funktions- eller klassbaserade view körs, frågar vanligtvis modeller och renderar en template, och returnerar ett `HttpResponse`. Undantag utlöser `process_exception`.
6. **Middleware, response-fas** — kod *efter* `get_response()` körs nedifrån-och-upp, vilket låter middleware modifiera den utgående responsen (headers, komprimering).
7. `HttpResponse` streamas tillbaka till servern och klienten.

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

def __call__(self, request):          # 2. request-fas (före)
        request.started = time.monotonic()
        response = self.get_response(request)  # anropar nästa lager / view
        response["X-Time"] = "..."         # 6. response-fas (efter)
        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)})
```

## Varför det är viktigt

Djangos request/response-cykel är middleware-centrerad, så det mesta av tvärgående beteende — auth, sessioner, CSRF, security headers, caching — implementeras som ordnad middleware. Att förstå att request-fas-kod körs uppifrån-och-ned och response-fas-kod körs nedifrån-och-upp (och att ordningen i `MIDDLEWARE` spelar roll) är avgörande för att placera din egen middleware korrekt, felsöka varför en `403`/redirect sker innan din view, och veta var du ska koppla in logik utan att röra varje view.

Stegen

Varför det är viktigt

Relaterade frågor