Kako deluje življenjski cikel zahteve v Django?

Question

IT Interview Practice · Accepted Answer

V Django zahtevo obravnava **WSGI/ASGI handler**, ovije jo sklad **middleware**, **URL resolver** jo usmeri do **view-a**, in se pretvori v `HttpResponse`, ki teče nazaj navzven skozi isti middleware v obratnem vrstnem redu.

## Faze

```
Web server ──▶ WSGI/ASGI handler  (ustvari HttpRequest)
   ▼
Middleware — faza request          (zgoraj → spodaj: __call__ pred get_response)
   ▼
URL resolver (urls.py)  ── ujemi path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── tvoja logika, vrne HttpResponse
   ▼
Middleware — faza response         (spodaj → zgoraj: po get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (sinhroni) ali ASGI (asinhroni) handler zgradi `HttpRequest` iz environ/scope.
2. **Middleware, faza request** — koda vsakega middlewara *pred* `get_response()` teče od zgoraj navzdol (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Kateri koli od njih lahko prekine verigo in predčasno vrne odgovor.
3. **Razreševanje URL** — vzorci `ROOT_URLCONF` se ujemajo s potjo, da se izbere view in zajamejo kwargs.
4. **`process_view`** — middleware hook, ki teče tik pred klicem view-a.
5. **View** — tvoj funkcijski ali razredni view teče, običajno poizveduje po modelih in izriše predlogo, ter vrne `HttpResponse`. Izjeme sprožijo `process_exception`.
6. **Middleware, faza response** — koda *po* `get_response()` teče od spodaj navzgor in middlewaru omogoča, da spremeni odhodni odgovor (glave, stiskanje).
7. `HttpResponse` se pretaka nazaj do strežnika in odjemalca.

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

def __call__(self, request):          # 2. faza request (pred)
        request.started = time.monotonic()
        response = self.get_response(request)  # pokliče naslednjo plast / view
        response["X-Time"] = "..."         # 6. faza response (po)
        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)})
```

## Zakaj je to pomembno

Cikel zahteva/odgovor v Django je osredotočen na middleware, zato je večina prečnega vedenja — auth, seje, CSRF, varnostne glave, predpomnjenje — implementirana kot urejeni middleware. Razumevanje, da koda faze request teče od zgoraj navzdol, koda faze response pa od spodaj navzgor (in da vrstni red v `MIDDLEWARE` šteje), je bistveno za pravilno umeščanje lastnega middlewara, razhroščevanje, zakaj se `403`/preusmeritev zgodi pred tvojim view-om, in vedenje, kam vpeti logiko, ne da bi se dotaknil vsakega view-a.

Faze

Zakaj je to pomembno

Povezana vprašanja