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

Question

IT Interview Practice · Accepted Answer

Ethvert endpoint, der returnerer en collection, skal **begrænse og forme** resultater. Tre hensyn — paginering, filtrering, sortering — bor alle i query string'en.

## Paginering: offset vs. cursor

**Offset (side-baseret)** — `?page=3&limit=20` eller `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Enkelt og tillader at hoppe til enhver side, men har to problemer ved skala: `OFFSET 100000` tvinger databasen til at scanne og kassere 100k rækker (langsomt), og hvis rækker indsættes/slettes mellem requests, **forskydes** elementerne, og du ser dubletter eller spring.

**Cursor (keyset)** — clienten sender en opaque pointer til det sidst sete element.
```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 oversætter cursoren til `WHERE id > 1020 ORDER BY id LIMIT 20` — et indekseret opslag, der forbliver hurtigt ved enhver dybde og er **stabilt** over for indsættelser. Afvejningen: ingen tilfældig adgang til "side 500".

```text
Offset  → små datasæt, admin-UI'er, "hop til side N"
Cursor  → store/uendelige feeds, real-time-data, mobil-scroll
```

## Filtrering og sortering

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Filtrér** med field=value-query-parametre (`status=shipped`). Whitelist de tilladte felter.
- **Sortér** med en `sort`-parameter; et `-`-præfiks betyder faldende (`-created_at`). Understøt multi-key for stabil rækkefølge.
- **Begræns altid `limit`** (fx maks. 100), så en client ikke kan anmode om en million rækker.

## Hvorfor det betyder noget

Dette er et af de mest praktiske API-designspørgsmål, fordi næsten ethvert liste-endpoint rammer det, og valget har reelle performance-konsekvenser. Intervieweren borer som regel i **offset-vs.-cursor-afvejningen**: en kandidat, der griber til offset-paginering overalt, har ikke mærket smerten ved `OFFSET 1000000`, der scanner tabellen, eller "shifting results"-buggen, hvor en bruger, der scroller et uendeligt feed, ser det samme opslag to gange, fordi et nyt blev indsat. Cursor-paginering løser begge ved at gøre forespørgslen til et indekseret keyset-opslag, hvilket er grunden til, at enhver storskala-API (Twitter, Stripe, Slack) bruger det til feeds. Stærke svar nævner også de driftsmæssige værn — whitelisting af filter-/sorterings-felter (for at undgå ikke-indekserede forespørgsler og injection) og begrænsning af `limit` (for at beskytte databasen) — hvilket adskiller en, der har kørt disse endpoints i produktion, fra en, der kun har læst om dem.

Paginering: offset vs. cursor

Filtrering og sortering

Hvorfor det betyder noget

Relaterede spørgsmål