Bagaimana Anda mendesain pagination, filtering, dan sorting untuk sebuah endpoint collection?

Question

IT Interview Practice · Accepted Answer

Endpoint apa pun yang mengembalikan sebuah collection perlu **membatasi dan membentuk** hasilnya. Tiga concern — pagination, filtering, sorting — semuanya berada di query string.

## Pagination: offset vs cursor

**Offset (berbasis page)** — `?page=3&limit=20` atau `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Sederhana dan memungkinkan melompat ke page mana pun, tetapi punya dua masalah pada skala besar: `OFFSET 100000` memaksa database memindai dan membuang 100k baris (lambat), dan jika baris disisipkan/dihapus di antara request, item **bergeser** dan Anda melihat duplikat atau lompatan.

**Cursor (keyset)** — client meneruskan pointer opak ke item terakhir yang terlihat.
```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 menerjemahkan cursor menjadi `WHERE id > 1020 ORDER BY id LIMIT 20` — sebuah lookup ber-index yang tetap cepat pada kedalaman berapa pun dan **stabil** terhadap penyisipan. Trade-off-nya: tidak ada akses acak ke "page 500".

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

## Filtering dan sorting

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Filter** dengan query param field=value (`status=shipped`). Whitelist field yang diizinkan.
- **Sort** dengan sebuah param `sort`; prefiks `-` berarti menurun (`-created_at`). Dukung multi-key untuk pengurutan yang stabil.
- Selalu **batasi `limit`** (mis. maks 100) agar client tidak bisa meminta sejuta baris.

## Mengapa ini penting

Ini adalah salah satu pertanyaan desain-API yang paling praktis karena hampir setiap endpoint daftar menghadapinya, dan pilihannya punya konsekuensi performa nyata. Pewawancara biasanya menyelidiki **trade-off offset-vs-cursor**: kandidat yang meraih offset pagination di mana-mana belum merasakan sakitnya `OFFSET 1000000` memindai tabel, atau bug "hasil bergeser" di mana pengguna yang menggulir feed tanpa batas melihat post yang sama dua kali karena ada yang baru disisipkan. Cursor pagination memperbaiki keduanya dengan mengubah query menjadi lookup keyset ber-index, itulah mengapa setiap API berskala besar (Twitter, Stripe, Slack) memakainya untuk feed. Jawaban yang kuat juga menyebut pagar pengaman operasional — whitelist field filter/sort (untuk menghindari query tanpa index dan injection) dan membatasi `limit` (untuk melindungi database) — yang memisahkan seseorang yang telah menjalankan endpoint ini di produksi dari seseorang yang hanya membacanya.

Pagination: offset vs cursor

Filtering dan sorting

Mengapa ini penting

Pertanyaan terkait