Bagaimana anda mereka bentuk paginasi, penapisan, dan pengisihan untuk endpoint koleksi?

Question

IT Interview Practice · Accepted Answer

Mana-mana endpoint yang memulangkan koleksi perlu **mengehad dan membentuk** hasil. Tiga kebimbangan — paginasi, penapisan, pengisihan — semuanya berada dalam query string.

## Paginasi: offset lawan cursor

**Offset (berasaskan halaman)** — `?page=3&limit=20` atau `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Ringkas dan membenarkan lompat ke mana-mana halaman, tetapi mempunyai dua masalah pada skala besar: `OFFSET 100000` memaksa pangkalan data mengimbas dan membuang 100k baris (perlahan), dan jika baris disisip/dipadam antara request, item **beralih** dan anda melihat pendua atau terlangkau.

**Cursor (keyset)** — client menghantar penunjuk legap ke item terakhir yang dilihat.
```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 menterjemah cursor kepada `WHERE id > 1020 ORDER BY id LIMIT 20` — carian berindeks yang kekal pantas pada sebarang kedalaman dan **stabil** terhadap sisipan. Trade-off: tiada capaian rawak ke "halaman 500".

```text
Offset  → dataset kecil, admin UI, "lompat ke halaman N"
Cursor  → feed besar/tak terhingga, data real-time, tatal pada mobile
```

## Penapisan dan pengisihan

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Tapis** dengan query param field=value (`status=shipped`). Whitelist medan yang dibenarkan.
- **Isih** dengan param `sort`; awalan `-` bermakna menurun (`-created_at`). Sokong berbilang kunci untuk susunan yang stabil.
- Sentiasa **hadkan `limit`** (cth. maksimum 100) supaya client tidak boleh meminta sejuta baris.

## Mengapa ia penting

Ini salah satu soalan reka bentuk API paling praktikal kerana hampir setiap endpoint senarai menghadapinya, dan pilihan itu mempunyai kesan prestasi sebenar. Penemu duga biasanya menyiasat **trade-off offset-lawan-cursor**: calon yang terus menggunakan offset di mana-mana belum merasai kesakitan `OFFSET 1000000` mengimbas jadual, atau bug "hasil beralih" di mana pengguna yang menatal feed tak terhingga melihat post yang sama dua kali kerana yang baharu telah disisip. Cursor pagination membaiki kedua-duanya dengan menukar query menjadi carian keyset berindeks, sebab itulah setiap API berskala besar (Twitter, Stripe, Slack) menggunakannya untuk feed. Jawapan yang kukuh juga menyebut pagar operasi — whitelist medan tapis/isih (untuk mengelakkan query tak berindeks dan injection) dan menghadkan `limit` (untuk melindungi pangkalan data) — yang memisahkan seseorang yang telah menjalankan endpoint ini dalam production daripada seseorang yang hanya membacanya.

Paginasi: offset lawan cursor

Penapisan dan pengisihan

Mengapa ia penting

Soalan berkaitan