Hogyan tervezel lapozást, szűrést és rendezést egy collection endpointhoz?

Question

IT Interview Practice · Accepted Answer

Bármely endpointnak, amely egy collectiont ad vissza, **korlátoznia és formálnia** kell az eredményeket. Három szempont — lapozás, szűrés, rendezés — mind a query stringben él.

## Lapozás: offset vs cursor

**Offset (oldal-alapú)** — `?page=3&limit=20` vagy `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Egyszerű, és lehetővé teszi bármelyik oldalra ugrást, de nagy méretben két problémája van: az `OFFSET 100000` arra kényszeríti az adatbázist, hogy 100k sort végigolvasson és eldobjon (lassú), és ha a kérések között sorok kerülnek beszúrásra/törlésre, az elemek **elcsúsznak**, és duplikátumokat vagy kimaradásokat látsz.

**Cursor (keyset)** — a kliens egy opaque pointert ad át az utoljára látott elemre.
```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 }
}
```
A server a cursort `WHERE id > 1020 ORDER BY id LIMIT 20`-ra fordítja — egy indexelt lookup, amely bármilyen mélységben gyors marad, és **stabil** a beszúrásokkal szemben. A kompromisszum: nincs véletlen hozzáférés az "500. oldalhoz".

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

## Szűrés és rendezés

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Szűrj** field=value query paraméterekkel (`status=shipped`). Whitelisteld az engedélyezett mezőket.
- **Rendezz** egy `sort` paraméterrel; a `-` prefix csökkenőt jelent (`-created_at`). Támogass több kulcsot a stabil rendezéshez.
- Mindig **korlátozd a `limit`-et** (pl. max 100), hogy egy kliens ne kérhessen le egymillió sort.

## Miért fontos

Ez az egyik legpraktikusabb API-tervezési kérdés, mert szinte minden lista-endpoint beleütközik, és a választásnak valós teljesítménybeli következményei vannak. Az interjúztató általában az **offset-vs-cursor kompromisszumot** firtatja: egy jelölt, aki mindenhol az offset-lapozáshoz nyúl, nem érezte az `OFFSET 1000000` táblavégigolvasás fájdalmát, vagy az "elcsúszó eredmények" bugot, ahol egy végtelen feedet görgető felhasználó kétszer látja ugyanazt a posztot, mert egy újat beszúrtak. A cursor-lapozás mindkettőt megoldja azzal, hogy a lekérdezést indexelt keyset-lookuppá alakítja, ezért használja minden nagy méretű API (Twitter, Stripe, Slack) a feedjeihez. Az erős válaszok az üzemeltetési védőkorlátokat is megemlítik — a szűrő/rendező mezők whitelistelését (az indexeletlen lekérdezések és az injection elkerülésére) és a `limit` korlátozását (az adatbázis védelmére) —, ami elválasztja azt, aki éles környezetben üzemeltette ezeket az endpointokat, attól, aki csak olvasott róluk.

Lapozás: offset vs cursor

Szűrés és rendezés

Miért fontos

Kapcsolódó kérdések