Hur designar du pagination, filtrering och sortering för en collection-endpoint?

Question

IT Interview Practice · Accepted Answer

Varje endpoint som returnerar en collection behöver **begränsa och forma** resultat. Tre bekymmer — pagination, filtrering, sortering — bor alla i query-strängen.

## Pagination: offset vs cursor

**Offset (page-baserad)** — `?page=3&limit=20` eller `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Enkel och tillåter hopp till vilken sida som helst, men har två problem vid skala: `OFFSET 100000` tvingar databasen att skanna och kasta 100k rader (långsamt), och om rader infogas/tas bort mellan requests **skiftar** poster och du ser dubbletter eller överhopp.

**Cursor (keyset)** — client:en skickar en opak pekare till den senast sedda posten.
```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 }
}
```
Servern översätter cursor:n till `WHERE id > 1020 ORDER BY id LIMIT 20` — en indexerad uppslagning som förblir snabb på vilket djup som helst och är **stabil** mot infogningar. Avvägningen: ingen slumpvis åtkomst till "sida 500".

```text
Offset  → små dataset, admin-UI:er, "hoppa till sida N"
Cursor  → stora/oändliga feeds, real-time-data, mobil-scroll
```

## Filtrering och sortering

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Filtrera** med field=value query-parametrar (`status=shipped`). Whitelista tillåtna fält.
- **Sortera** med en `sort`-parameter; ett `-`-prefix betyder fallande (`-created_at`). Stöd multi-key för stabil ordning.
- **Begränsa alltid `limit`** (t.ex. max 100) så att en client inte kan begära en miljon rader.

## Varför det är viktigt

Detta är en av de mest praktiska API-designfrågorna eftersom nästan varje list-endpoint stöter på den, och valet har verkliga prestandakonsekvenser. Intervjuaren undersöker oftast **avvägningen offset-vs-cursor**: en kandidat som griper efter offset-pagination överallt har inte känt smärtan av `OFFSET 1000000` som skannar tabellen, eller "skiftande resultat"-buggen där en användare som scrollar en oändlig feed ser samma inlägg två gånger eftersom ett nytt infogades. Cursor-pagination fixar båda genom att förvandla frågan till en indexerad keyset-uppslagning, vilket är varför varje storskaligt API (Twitter, Stripe, Slack) använder det för feeds. Starka svar nämner också driftsräckena — att whitelista filter-/sort-fält (för att undvika oindexerade frågor och injection) och att begränsa `limit` (för att skydda databasen) — vilket skiljer någon som har kört dessa endpoints i produktion från någon som bara har läst om dem.

Pagination: offset vs cursor

Filtrering och sortering

Varför det är viktigt

Relaterade frågor