Πώς σχεδιάζετε pagination, filtering, και sorting για ένα endpoint collection;

Question

IT Interview Practice · Accepted Answer

Κάθε endpoint που επιστρέφει μια collection χρειάζεται να περιορίσει και να διαμορφώσει τα αποτελέσματα. Τρία ζητήματα — pagination, filtering, sorting — ζουν όλα στο query string.

Pagination: offset vs cursor

Offset (βασισμένο σε σελίδες) — ?page=3&limit=20 ή ?offset=40&limit=20.

## Pagination: offset vs cursor

**Offset (βασισμένο σε σελίδες)** — `?page=3&limit=20` ή `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
Απλό και επιτρέπει άλμα σε οποιαδήποτε σελίδα, αλλά έχει δύο προβλήματα σε κλίμακα: το `OFFSET 100000` αναγκάζει τη βάση δεδομένων να σαρώσει και να απορρίψει 100k γραμμές (αργό), και αν γραμμές εισαχθούν/διαγραφούν μεταξύ των requests, τα στοιχεία **μετατοπίζονται** και βλέπετε διπλότυπα ή παραλείψεις.

**Cursor (keyset)** — ο client περνάει έναν αδιαφανή δείκτη προς το τελευταίο στοιχείο που είδε.
```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 }
}
```
Ο server μεταφράζει τον cursor σε `WHERE id > 1020 ORDER BY id LIMIT 20` — μια αναζήτηση με χρήση index που παραμένει γρήγορη σε οποιοδήποτε βάθος και είναι **σταθερή** έναντι εισαγωγών. Η ανταλλαγή: καμία τυχαία πρόσβαση στη "σελίδα 500".

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

## Filtering και sorting

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- **Filter** με query params της μορφής field=value (`status=shipped`). Κάντε whitelist τα επιτρεπόμενα πεδία.
- **Sort** με ένα param `sort`· ένα πρόθεμα `-` σημαίνει φθίνουσα σειρά (`-created_at`). Υποστηρίξτε multi-key για σταθερή διάταξη.
- Πάντα **περιορίζετε το `limit`** (π.χ. μέγιστο 100) ώστε ένας client να μην μπορεί να ζητήσει ένα εκατομμύριο γραμμές.

## Γιατί έχει σημασία

Αυτή είναι μία από τις πιο πρακτικές ερωτήσεις σχεδίασης API επειδή σχεδόν κάθε endpoint λίστας τη συναντά, και η επιλογή έχει πραγματικές συνέπειες στις επιδόσεις. Ο συνεντευξιαστής συνήθως εξετάζει την **ανταλλαγή offset-vs-cursor**: ένας υποψήφιος που καταφεύγει σε offset pagination παντού δεν έχει νιώσει τον πόνο του `OFFSET 1000000` να σαρώνει τον πίνακα, ή το bug των "μετατοπιζόμενων αποτελεσμάτων" όπου ένας χρήστης που κάνει scroll σε ένα άπειρο feed βλέπει το ίδιο post δύο φορές επειδή ένα νέο εισήχθη. Το cursor pagination διορθώνει και τα δύο μετατρέποντας το query σε μια αναζήτηση keyset με index, γι' αυτό κάθε API μεγάλης κλίμακας (Twitter, Stripe, Slack) το χρησιμοποιεί για feeds. Οι δυνατές απαντήσεις αναφέρουν επίσης τις λειτουργικές δικλείδες ασφαλείας — whitelisting των πεδίων filter/sort (για την αποφυγή μη indexed queries και injection) και τον περιορισμό του `limit` (για την προστασία της βάσης δεδομένων) — πράγμα που ξεχωρίζει κάποιον που έχει τρέξει αυτά τα endpoints στην παραγωγή από κάποιον που έχει μόνο διαβάσει γι' αυτά.

Pagination: offset vs cursor

Filtering και sorting

Γιατί έχει σημασία

Σχετικές ερωτήσεις