Bagaimanakah kitaran hayat request berfungsi dalam Django?

Question

IT Interview Practice · Accepted Answer

Dalam Django, sesuatu request dikendalikan oleh **WSGI/ASGI handler**, dibalut oleh satu tumpukan **middleware**, dihalakan oleh **URL resolver** kepada sesuatu **view**, dan ditukar menjadi satu `HttpResponse` yang mengalir semula keluar melalui middleware yang sama secara terbalik.

## Peringkat-peringkatnya

```
Web server ──▶ WSGI/ASGI handler  (mencipta HttpRequest)
   ▼
Middleware — fasa request         (atas → bawah: __call__ sebelum get_response)
   ▼
URL resolver (urls.py)  ── padankan path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── logik anda, memulangkan HttpResponse
   ▼
Middleware — fasa response         (bawah → atas: selepas get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (sync) atau ASGI (async) handler membina satu `HttpRequest` daripada environ/scope.
2. **Middleware, fasa request** — kod setiap middleware *sebelum* `get_response()` berjalan dari atas ke bawah (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Mana-mana antaranya boleh memintas awal dan memulangkan response lebih awal.
3. **URL resolution** — pattern `ROOT_URLCONF` dipadankan dengan path untuk memilih sesuatu view dan menangkap kwargs.
4. **`process_view`** — satu hook middleware yang berjalan sejurus sebelum view dipanggil.
5. **View** — view berbentuk function atau class-based anda berjalan, biasanya membuat query pada model dan render sesuatu template, dan memulangkan satu `HttpResponse`. Exception mencetuskan `process_exception`.
6. **Middleware, fasa response** — kod *selepas* `get_response()` berjalan dari bawah ke atas, membenarkan middleware mengubah response yang keluar (headers, pemampatan).
7. `HttpResponse` distream semula kepada server dan client.

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

def __call__(self, request):          # 2. fasa request (sebelum)
        request.started = time.monotonic()
        response = self.get_response(request)  # memanggil lapisan seterusnya / view
        response["X-Time"] = "..."         # 6. fasa response (selepas)
        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)})
```

## Mengapa ia penting

Kitaran request/response Django berpusatkan middleware, jadi kebanyakan tingkah laku merentas (cross-cutting) — auth, session, CSRF, security headers, caching — dilaksanakan sebagai middleware yang tersusun. Memahami bahawa kod fasa request berjalan dari atas ke bawah dan kod fasa response berjalan dari bawah ke atas (dan bahawa susunan dalam `MIDDLEWARE` adalah penting) amat perlu untuk meletakkan middleware anda sendiri dengan betul, menyahpepijat mengapa sesuatu `403`/redirect berlaku sebelum view anda, dan mengetahui di mana hendak mengaitkan logik tanpa menyentuh setiap view.

Peringkat-peringkatnya

Mengapa ia penting

Soalan berkaitan