Cum funcționează ciclul de viață al unei cereri în Django?

Question

IT Interview Practice · Accepted Answer

În Django, o cerere este gestionată de **WSGI/ASGI handler**, învelită de o stivă de **middleware**, direcționată de **URL resolver** către un **view** și transformată într-un `HttpResponse` care curge înapoi în afară prin același middleware, în ordine inversă.

## Etapele

```
Web server ──▶ WSGI/ASGI handler  (creează HttpRequest)
   ▼
Middleware — faza request          (sus → jos: __call__ înainte de get_response)
   ▼
URL resolver (urls.py)  ── potrivește path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── logica ta, returnează HttpResponse
   ▼
Middleware — faza response         (jos → sus: după get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — handler-ul WSGI (sincron) sau ASGI (asincron) construiește un `HttpRequest` din environ/scope.
2. **Middleware, faza request** — codul fiecărui middleware *dinainte* de `get_response()` rulează de sus în jos (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Oricare dintre ele poate scurtcircuita și returna un răspuns mai devreme.
3. **Rezolvarea URL** — tiparele din `ROOT_URLCONF` sunt potrivite cu calea pentru a selecta un view și a captura kwargs.
4. **`process_view`** — un hook de middleware care rulează chiar înainte ca view-ul să fie apelat.
5. **View** — view-ul tău bazat pe funcție sau clasă rulează, de obicei interoghează modele și randează un template, și returnează un `HttpResponse`. Excepțiile declanșează `process_exception`.
6. **Middleware, faza response** — codul *de după* `get_response()` rulează de jos în sus, permițând middleware-ului să modifice răspunsul de ieșire (antete, compresie).
7. `HttpResponse` este transmis înapoi către server și client.

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

def __call__(self, request):          # 2. faza request (înainte)
        request.started = time.monotonic()
        response = self.get_response(request)  # apelează stratul următor / view
        response["X-Time"] = "..."         # 6. faza response (după)
        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)})
```

## De ce contează

Ciclul cerere/răspuns al Django este centrat pe middleware, deci cea mai mare parte a comportamentului transversal — auth, sesiuni, CSRF, antete de securitate, caching — este implementată ca middleware ordonat. Înțelegerea faptului că codul fazei request rulează de sus în jos, iar codul fazei response de jos în sus (și că ordinea din `MIDDLEWARE` contează) este esențială pentru a-ți plasa corect propriul middleware, a depana de ce un `403`/redirect se întâmplă înaintea view-ului tău și a ști unde să conectezi logica fără a atinge fiecare view.

Etapele

De ce contează

Întrebări conexe