Mzunguko wa maisha wa request unafanyaje kazi katika Django?

Question

IT Interview Practice · Accepted Answer

Katika Django, request hushughulikiwa na **WSGI/ASGI handler**, kufungwa na rundo la **middleware**, kuelekezwa na **URL resolver** kwenda **view**, na kubadilishwa kuwa `HttpResponse` inayotiririka kurudi nje kupitia middleware ile ile kwa mpangilio wa kinyume.

## Hatua

```
Web server ──▶ WSGI/ASGI handler  (huunda HttpRequest)
   ▼
Middleware — awamu ya request        (juu → chini: __call__ kabla ya get_response)
   ▼
URL resolver (urls.py)  ── linganisha path → view + kwargs
   ▼
Middleware — hook ya process_view
   ▼
View (function / class-based)  ── mantiki yako, hurejesha HttpResponse
   ▼
Middleware — awamu ya response        (chini → juu: baada ya get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (sync) au ASGI (async) handler hujenga `HttpRequest` kutoka environ/scope.
2. **Middleware, awamu ya request** — code ya kila middleware *kabla* ya `get_response()` huendeshwa juu-kwenda-chini (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Yoyote kati yao inaweza kukatiza na kurejesha response mapema.
3. **URL resolution** — mifumo ya `ROOT_URLCONF` hulinganishwa na path ili kuchagua view na kunasa kwargs.
4. **`process_view`** — hook ya middleware inayoendeshwa mara moja kabla ya view kuitwa.
5. **View** — view yako ya function au class huendeshwa, kwa kawaida ikihoji models na kutoa template, na hurejesha `HttpResponse`. Hitilafu huchochea `process_exception`.
6. **Middleware, awamu ya response** — code *baada* ya `get_response()` huendeshwa chini-kwenda-juu, ikiruhusu middleware kurekebisha response inayotoka (headers, compression).
7. `HttpResponse` hutiririshwa kurudi kwa server na client.

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

def __call__(self, request):          # 2. awamu ya request (kabla)
        request.started = time.monotonic()
        response = self.get_response(request)  # huita tabaka linalofuata / view
        response["X-Time"] = "..."         # 6. awamu ya response (baada)
        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)})
```

## Kwa nini ni muhimu

Mzunguko wa request/response wa Django unazingatia middleware, kwa hivyo tabia nyingi zinazovuka tabaka — auth, sessions, CSRF, security headers, caching — hutekelezwa kama middleware yenye mpangilio. Kuelewa kuwa code ya awamu ya request huendeshwa juu-kwenda-chini na code ya awamu ya response huendeshwa chini-kwenda-juu (na kwamba mpangilio katika `MIDDLEWARE` ni muhimu) ni jambo la msingi kuweka middleware yako kwa usahihi, kutatua kwa nini `403`/redirect hutokea kabla ya view yako, na kujua wapi pa kuunganisha mantiki bila kugusa kila view.

Hatua

Kwa nini ni muhimu

Maswali yanayohusiana