request lifecycle ทำงานอย่างไรใน Django?

Question

IT Interview Practice · Accepted Answer

ใน Django, request จะถูกจัดการโดย **WSGI/ASGI handler**, ห่อหุ้มด้วยสแตกของ **middleware**, กำหนดเส้นทางโดย **URL resolver** ไปยัง **view**, และแปลงเป็น `HttpResponse` ที่ไหลย้อนกลับออกไปผ่าน middleware ชุดเดิมในลำดับกลับด้าน

## ขั้นตอนต่างๆ

```
Web server ──▶ WSGI/ASGI handler  (สร้าง HttpRequest)
   ▼
Middleware — เฟส request        (บน → ล่าง: __call__ ก่อน get_response)
   ▼
URL resolver (urls.py)  ── จับคู่ path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── logic ของคุณ, คืนค่า HttpResponse
   ▼
Middleware — เฟส response        (ล่าง → บน: หลัง get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (sync) หรือ ASGI (async) handler สร้าง `HttpRequest` จาก environ/scope
2. **Middleware, เฟส request** — โค้ดของแต่ละ middleware *ก่อน* `get_response()` ทำงานจากบนลงล่าง (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …) ตัวใดก็ได้สามารถลัดวงจรและคืน response กลับไปก่อนเวลาได้
3. **URL resolution** — pattern ใน `ROOT_URLCONF` ถูกจับคู่กับ path เพื่อเลือก view และจับ kwargs
4. **`process_view`** — hook ของ middleware ที่ทำงานก่อนที่ view จะถูกเรียกเพียงเล็กน้อย
5. **View** — view แบบ function หรือ class-based ของคุณทำงาน โดยทั่วไปจะ query models และ render template แล้วคืน `HttpResponse` ข้อยกเว้นจะทริกเกอร์ `process_exception`
6. **Middleware, เฟส response** — โค้ด *หลัง* `get_response()` ทำงานจากล่างขึ้นบน ทำให้ middleware ปรับแต่ง response ที่ส่งออก (headers, compression) ได้
7. `HttpResponse` จะถูก stream กลับไปยัง server และ client

```python
# 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
        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)})
```

## ทำไมจึงสำคัญ

วงจร request/response ของ Django มี middleware เป็นศูนย์กลาง ดังนั้นพฤติกรรมแบบ cross-cutting ส่วนใหญ่ — auth, sessions, CSRF, security headers, caching — จึงถูกทำให้เป็น middleware ที่มีลำดับ การเข้าใจว่าโค้ดเฟส request ทำงานจากบนลงล่างและโค้ดเฟส response ทำงานจากล่างขึ้นบน (และลำดับใน `MIDDLEWARE` มีความสำคัญ) เป็นสิ่งจำเป็นในการวาง middleware ของคุณเองอย่างถูกต้อง, debug ว่าทำไม `403`/redirect จึงเกิดขึ้นก่อน view ของคุณ, และรู้ว่าจะ hook logic ไว้ที่ไหนโดยไม่ต้องแตะทุก view

ขั้นตอนต่างๆ

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง