คุณออกแบบการแบ่งหน้า การกรอง และการจัดเรียงสำหรับ endpoint แบบ collection อย่างไร?

Question

IT Interview Practice · Accepted Answer

endpoint ใดก็ตามที่คืน collection จำเป็นต้อง จำกัดและจัดรูป ผลลัพธ์ ความกังวลสามเรื่อง — การแบ่งหน้า, การกรอง, การจัดเรียง — ล้วนอยู่ใน query string

การแบ่งหน้า: offset vs cursor

Offset (อิงหน้า) — ?page=3&limit=20 หรือ ?offset=40&limit=20

http

GET /orders?offset=40&limit=20 HTTP/1.1

## การแบ่งหน้า: offset vs cursor

**Offset (อิงหน้า)** — `?page=3&limit=20` หรือ `?offset=40&limit=20`
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
เรียบง่ายและกระโดดไปหน้าไหนก็ได้ แต่มีสองปัญหาเมื่อสเกลใหญ่: `OFFSET 100000` บังคับให้ฐานข้อมูลสแกนและทิ้ง 100k แถว (ช้า) และหากมีแถวถูกแทรก/ลบระหว่าง request รายการจะ **เลื่อน** ทำให้คุณเห็นข้อมูลซ้ำหรือตกหล่น

**Cursor (keyset)** — client ส่งพอยน์เตอร์แบบทึบ (opaque) ที่ชี้ไปยังรายการสุดท้ายที่เห็น
```http
GET /orders?limit=20&cursor=eyJpZCI6MTAyMH0 HTTP/1.1
```
```http
HTTP/1.1 200 OK

{
  "data": [ /* 20 orders */ ],
  "page": { "next_cursor": "eyJpZCI6MTA0MH0", "has_more": true }
}
```
server แปล cursor เป็น `WHERE id > 1020 ORDER BY id LIMIT 20` — การค้นแบบใช้ index ที่ยังเร็วอยู่ที่ทุกความลึกและ **เสถียร** ต่อการแทรก การแลกเปลี่ยน: ไม่มีการเข้าถึงแบบสุ่มไป "หน้า 500"

```text
Offset  → small datasets, admin UIs, "jump to page N"
Cursor  → large/infinite feeds, real-time data, mobile scroll
```

## การกรองและการจัดเรียง

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **กรอง** ด้วย query param แบบ field=value (`status=shipped`) ทำ whitelist ฟิลด์ที่อนุญาต
- **จัดเรียง** ด้วย param `sort`; คำนำหน้า `-` หมายถึงเรียงจากมากไปน้อย (`-created_at`) รองรับหลายคีย์เพื่อลำดับที่เสถียร
- **จำกัด `limit`** เสมอ (เช่น สูงสุด 100) เพื่อไม่ให้ client ขอเป็นล้านแถว

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

นี่เป็นหนึ่งในคำถามออกแบบ API ที่ใช้งานได้จริงที่สุด เพราะแทบทุก endpoint แบบรายการเจอมัน และการเลือกมีผลด้านประสิทธิภาพจริง ผู้สัมภาษณ์มักเจาะ **การแลกเปลี่ยน offset-vs-cursor**: ผู้สมัครที่คว้า offset pagination ไปใช้ทุกที่ ยังไม่เคยเจ็บกับ `OFFSET 1000000` ที่สแกนทั้งตาราง หรือบั๊ก "ผลลัพธ์เลื่อน" ที่ผู้ใช้เลื่อน feed ไม่สิ้นสุดแล้วเห็นโพสต์เดิมสองครั้งเพราะมีโพสต์ใหม่ถูกแทรกเข้ามา Cursor pagination แก้ทั้งสองด้วยการเปลี่ยน query ให้เป็น keyset lookup ที่ใช้ index จึงเป็นเหตุว่าทำไมทุก API สเกลใหญ่ (Twitter, Stripe, Slack) จึงใช้มันกับ feed คำตอบที่แข็งแรงยังกล่าวถึงราวกันตกเชิงปฏิบัติการ — การ whitelist ฟิลด์กรอง/จัดเรียง (เพื่อเลี่ยง query ที่ไม่ใช้ index และ injection) และการจำกัด `limit` (เพื่อปกป้องฐานข้อมูล) — ซึ่งแยกคนที่เคยรัน endpoint เหล่านี้ใน production ออกจากคนที่อ่านมาแต่ทฤษฎี

การแบ่งหน้า: offset vs cursor

การกรองและการจัดเรียง

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

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