Hvordan designer du paginering, filtrering og sortering for et collection-endepunkt?

Question

IT Interview Practice · Accepted Answer

Ethvert endepunkt som returnerer en collection må **begrense og forme** resultatene. Tre hensyn — paginering, filtrering, sortering — ligger alle i query-strengen.

## Paginering: offset vs cursor

**Offset (sidebasert)** — `?page=3&limit=20` eller `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Enkelt og lar deg hoppe til hvilken som helst side, men har to problemer i stor skala: `OFFSET 100000` tvinger databasen til å skanne og forkaste 100k rader (tregt), og hvis rader settes inn/slettes mellom requests, **forskyves** elementene og du ser duplikater eller hopp.

**Cursor (keyset)** — klienten sender en ugjennomsiktig peker til det siste elementet den så.
```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 }
}
```
Serveren oversetter cursor-en til `WHERE id > 1020 ORDER BY id LIMIT 20` — et indeksert oppslag som holder seg raskt på hvilken som helst dybde og er **stabilt** mot innsettinger. Avveiingen: ingen vilkårlig tilgang til "side 500".

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

## Filtrering og sortering

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Filtrer** med field=value query-parametere (`status=shipped`). Whitelist tillatte felter.
- **Sortér** med et `sort`-parameter; et `-`-prefiks betyr synkende (`-created_at`). Støtt flere nøkler for stabil rekkefølge.
- **Begrens alltid `limit`** (f.eks. maks 100) slik at en klient ikke kan be om en million rader.

## Hvorfor det er viktig

Dette er et av de mest praktiske API-designspørsmålene fordi nesten hvert liste-endepunkt møter det, og valget har reelle ytelseskonsekvenser. Intervjueren graver som regel i **offset-vs-cursor-avveiingen**: en kandidat som griper til offset-paginering overalt har ikke kjent smerten ved `OFFSET 1000000` som skanner tabellen, eller "forskjøvne resultater"-feilen der en bruker som scroller en uendelig feed ser samme post to ganger fordi en ny ble satt inn. Cursor-paginering fikser begge ved å gjøre spørringen om til et indeksert keyset-oppslag, som er grunnen til at hvert storskala-API (Twitter, Stripe, Slack) bruker det for feeder. Sterke svar nevner også de operasjonelle rekkverkene — whitelisting av filter-/sorteringsfelter (for å unngå uindekserte spørringer og injeksjon) og begrensning av `limit` (for å beskytte databasen) — som skiller noen som har kjørt disse endepunktene i produksjon fra noen som bare har lest om dem.

Paginering: offset vs cursor

Filtrering og sortering

Hvorfor det er viktig

Relaterte spørsmål