Wie gestaltest du Pagination, Filtering und Sorting für einen Collection-Endpoint?

Question

IT Interview Practice · Accepted Answer

Jeder Endpoint, der eine Collection zurückgibt, muss die Ergebnisse **begrenzen und formen**. Drei Belange — Pagination, Filtering, Sorting — leben alle im Query String.

## Pagination: Offset vs. Cursor

**Offset (seitenbasiert)** — `?page=3&limit=20` oder `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Einfach und erlaubt das Springen zu jeder Seite, hat aber zwei Probleme bei Skalierung: `OFFSET 100000` zwingt die Datenbank, 100k Zeilen zu scannen und zu verwerfen (langsam), und wenn Zeilen zwischen Requests eingefügt/gelöscht werden, **verschieben** sich Elemente und du siehst Duplikate oder Auslassungen.

**Cursor (Keyset)** — der Client übergibt einen opaken Zeiger auf das zuletzt gesehene 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 }
}
```
Der Server übersetzt den Cursor in `WHERE id > 1020 ORDER BY id LIMIT 20` — ein indizierter Lookup, der in jeder Tiefe schnell bleibt und **stabil** gegen Einfügungen ist. Der Trade-off: kein wahlfreier Zugriff auf "Seite 500".

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

## Filtering und Sorting

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Filtere** mit field=value-Query-Parametern (`status=shipped`). Whiteliste erlaubte Felder.
- **Sortiere** mit einem `sort`-Parameter; ein `-`-Präfix bedeutet absteigend (`-created_at`). Unterstütze mehrere Schlüssel für stabile Ordnung.
- **Begrenze `limit` immer** (z. B. max. 100), damit ein Client nicht eine Million Zeilen anfordern kann.

## Warum es wichtig ist

Dies ist eine der praktischsten API-Design-Fragen, weil nahezu jeder Listen-Endpoint darauf trifft und die Wahl echte Performance-Konsequenzen hat. Der Interviewer sondiert meist den **Offset-vs.-Cursor-Trade-off**: ein Kandidat, der überall zu Offset-Pagination greift, hat den Schmerz von `OFFSET 1000000` beim Scannen der Tabelle nicht gespürt, oder den "Shifting Results"-Bug, bei dem ein Nutzer, der einen Infinite Feed scrollt, denselben Post zweimal sieht, weil ein neuer eingefügt wurde. Cursor-Pagination behebt beides, indem sie die Query in einen indizierten Keyset-Lookup verwandelt, weshalb jede große API (Twitter, Stripe, Slack) sie für Feeds verwendet. Starke Antworten erwähnen auch die operativen Leitplanken — Whitelisting von Filter-/Sort-Feldern (um unindizierte Queries und Injection zu vermeiden) und das Begrenzen von `limit` (um die Datenbank zu schützen) — was jemanden, der diese Endpoints in Produktion betrieben hat, von jemandem trennt, der nur darüber gelesen hat.

Pagination: Offset vs. Cursor

Filtering und Sorting

Warum es wichtig ist

Ähnliche Fragen