Jak funguje životní cyklus požadavku v Django?

Question

IT Interview Practice · Accepted Answer

V Django zpracuje požadavek **WSGI/ASGI handler**, obalí jej zásobník **middleware**, **URL resolver** jej nasměruje na **view** a promění se v `HttpResponse`, který proudí zpět ven skrz stejné middleware v opačném pořadí.

## Fáze

```
Web server ──▶ WSGI/ASGI handler  (vytvoří HttpRequest)
   ▼
Middleware — fáze požadavku        (shora → dolů: __call__ před get_response)
   ▼
URL resolver (urls.py)  ── porovná path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── vaše logika, vrací HttpResponse
   ▼
Middleware — fáze odpovědi        (zdola → nahoru: po get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (synchronní) nebo ASGI (asynchronní) handler sestaví `HttpRequest` z environ/scope.
2. **Middleware, fáze požadavku** — kód každého middleware *před* `get_response()` běží shora dolů (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Kterýkoli z nich může proces zkratovat a vrátit odpověď předčasně.
3. **Rozlišení URL** — vzory `ROOT_URLCONF` se porovnají s cestou, aby se vybralo view a zachytily kwargs.
4. **`process_view`** — hook middleware, který běží těsně před voláním view.
5. **View** — vaše view (funkce nebo třída) běží, obvykle dotazuje modely a vykresluje šablonu, a vrací `HttpResponse`. Výjimky spouštějí `process_exception`.
6. **Middleware, fáze odpovědi** — kód *po* `get_response()` běží zdola nahoru a umožňuje middleware upravit odchozí odpověď (hlavičky, komprese).
7. `HttpResponse` se streamuje zpět na server a klientovi.

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

def __call__(self, request):          # 2. fáze požadavku (před)
        request.started = time.monotonic()
        response = self.get_response(request)  # volá další vrstvu / view
        response["X-Time"] = "..."         # 6. fáze odpovědi (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)})
```

## Proč je to důležité

Cyklus požadavek/odpověď v Django je zaměřený na middleware, takže většina průřezového chování — autentizace, session, CSRF, bezpečnostní hlavičky, cachování — je implementována jako uspořádaný middleware. Pochopení, že kód fáze požadavku běží shora dolů a kód fáze odpovědi zdola nahoru (a že na pořadí v `MIDDLEWARE` záleží), je zásadní pro správné umístění vlastního middleware, ladění, proč se `403`/přesměrování stane před vaším view, a pro znalost, kam napojit logiku, aniž byste se dotkli každého view.

Fáze

Proč je to důležité

Související otázky