Miten pyynnön elinkaari toimii Djangossa?

Question

IT Interview Practice · Accepted Answer

Djangossa pyynnön käsittelee **WSGI/ASGI-handler**, sen kietoo **middleware**-pino, **URL-resolver** reitittää sen **view**iin, ja se muuttuu `HttpResponse`ksi, joka virtaa takaisin ulos saman middlewaren läpi käänteisessä järjestyksessä.

## Vaiheet

```
Web-palvelin ──▶ WSGI/ASGI-handler  (luo HttpRequestin)
   ▼
Middleware — request-vaihe         (ylhäältä → alas: __call__ ennen get_responsea)
   ▼
URL-resolver (urls.py)  ── täsmää path → view + kwargs
   ▼
Middleware — process_view-hook
   ▼
View (funktio / class-based)  ── logiikkasi, palauttaa HttpResponsen
   ▼
Middleware — response-vaihe         (alhaalta → ylös: get_responsen jälkeen)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (synkroninen) tai ASGI (asynkroninen) handler rakentaa `HttpRequest`in environ/scopesta.
2. **Middleware, request-vaihe** — jokaisen middlewaren koodi *ennen* `get_response()`a ajetaan ylhäältä alas (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Mikä tahansa niistä voi oikaista ja palauttaa responsen aikaisin.
3. **URL-resolvointi** — `ROOT_URLCONF`-patternit täsmätään polkuun, jotta valitaan view ja napataan kwargsit.
4. **`process_view`** — middleware-hook, joka ajetaan juuri ennen kuin view kutsutaan.
5. **View** — funktio- tai class-based-viewisi ajetaan, tyypillisesti kyselee malleja ja renderöi templaten, ja palauttaa `HttpResponse`n. Poikkeukset laukaisevat `process_exception`in.
6. **Middleware, response-vaihe** — koodi *jälkeen* `get_response()`n ajetaan alhaalta ylös, jolloin middleware voi muokata ulosmenevää responsea (headerit, pakkaus).
7. `HttpResponse` striimataan takaisin palvelimelle ja clientille.

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

def __call__(self, request):          # 2. request-vaihe (ennen)
        request.started = time.monotonic()
        response = self.get_response(request)  # kutsuu seuraavaa kerrosta / viewia
        response["X-Time"] = "..."         # 6. response-vaihe (jälkeen)
        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)})
```

## Miksi se on tärkeää

Djangon request/response-sykli on middleware-keskeinen, joten suurin osa läpileikkaavasta käyttäytymisestä — auth, sessiot, CSRF, security-headerit, caching — on toteutettu järjestettynä middlewarena. Sen ymmärtäminen, että request-vaiheen koodi ajetaan ylhäältä alas ja response-vaiheen koodi alhaalta ylös (ja että järjestyksellä `MIDDLEWARE`ssa on merkitystä) on olennaista oman middlewaren sijoittamiseksi oikein, sen debuggaamiseksi miksi `403`/redirect tapahtuu ennen viewiäsi, ja sen tietämiseksi mihin kytkeä logiikka koskematta jokaiseen viewiin.

Vaiheet

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset