Django में, एक request को WSGI/ASGI handler द्वारा handle किया जाता है, middleware के एक stack द्वारा लपेटा जाता है, URL resolver द्वारा एक view तक route किया जाता है, और एक HttpResponse में बदल दिया जाता है जो उसी middleware से उल्टे क्रम में वापस बाहर बहती है.
Web server ──▶ WSGI/ASGI handler (HttpRequest बनाता है)
▼
Middleware — request चरण (ऊपर → नीचे: get_response से पहले __call__)
▼
URL resolver (urls.py) ── path match करें → view + kwargs
▼
Middleware — process_view hook
▼
View (function / class-based) ── आपका logic, HttpResponse लौटाता है
▼
Middleware — response चरण (नीचे → ऊपर: get_response के बाद)
▼
HttpResponse ──▶ client
HttpRequest बनाता है.get_response() से पहले वाला code ऊपर-से-नीचे चलता है (SecurityMiddleware, SessionMiddleware, AuthenticationMiddleware, CSRF, …). इनमें से कोई भी short-circuit कर सकता है और जल्दी एक response लौटा सकता है.ROOT_URLCONF patterns को path के विरुद्ध match किया जाता है.process_view — एक middleware hook जो view को call किए जाने से ठीक पहले चलता है.HttpResponse लौटाता है. Exceptions process_exception को trigger करती हैं.get_response() के बाद वाला code नीचे-से-ऊपर चलता है, जिससे middleware बाहर जाती response (headers, compression) को modify कर सकता है.HttpResponse को वापस server और client तक stream किया जाता है.# middleware.py
class TimingMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request): # 2. request चरण (पहले)
request.started = time.monotonic()
response = self.get_response(request) # अगली layer / view को call करता है
response["X-Time"] = "..." # 6. response चरण (बाद में)
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)})
Django का request/response cycle middleware-केंद्रित है, इसलिए अधिकांश cross-cutting behavior — auth, sessions, CSRF, security headers, caching — क्रमबद्ध middleware के रूप में लागू किया जाता है. यह समझना कि request-चरण का code ऊपर-से-नीचे चलता है और response-चरण का code नीचे-से-ऊपर चलता है (और MIDDLEWARE में क्रम मायने रखता है) आपके अपने middleware को सही ढंग से रखने, यह debug करने कि कोई 403/redirect आपके view से पहले क्यों होता है, और यह जानने के लिए आवश्यक है कि प्रत्येक view को छुए बिना logic को कहाँ hook करना है.
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें