როგორ ააგებ pagination-ს, filtering-სა და sorting-ს კოლექციის endpoint-ისთვის?

Question

IT Interview Practice · Accepted Answer

ნებისმიერ endpoint-ს, რომელიც კოლექციას აბრუნებს, სჭირდება შედეგების შეზღუდვა და ფორმირება. სამი საზრუნავი — pagination, filtering, sorting — ყველა query string-ში ცხოვრობს.

Pagination: offset vs cursor

Offset (page-ზე დაფუძნებული) — ?page=3&limit=20 ან ?offset=40&limit=20.

## Pagination: offset vs cursor

**Offset (page-ზე დაფუძნებული)** — `?page=3&limit=20` ან `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
მარტივი და საშუალებას იძლევა ნებისმიერ page-ზე გადახტომის, მაგრამ მასშტაბზე ორი პრობლემა აქვს: `OFFSET 100000` აიძულებს database-ს დაასკანიროს და გადააგდოს 100k სტრიქონი (ნელი), და თუ სტრიქონები ჩაისმება/წაიშლება request-ებს შორის, ელემენტები **იძვრება** და დუბლიკატებს ან გამოტოვებებს ხედავთ.

**Cursor (keyset)** — client გადასცემს გაუმჭვირვალე pointer-ს ბოლო ნანახ ელემენტზე.
```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`-ად — ინდექსირებული ძებნა, რომელიც ნებისმიერ სიღრმეზე სწრაფი რჩება და **სტაბილურია** ჩასმების მიმართ. ტრეიდ-ოფი: „page 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** field=value query param-ებით (`status=shipped`). Whitelist-ში ჩასვით ნებადართული ველები.
- **Sort** `sort` param-ით; `-` პრეფიქსი კლებადს ნიშნავს (`-created_at`). მხარი დაუჭირეთ მრავალ-key-ს სტაბილური დალაგებისთვის.
- ყოველთვის **შეზღუდეთ `limit`** (მაგ. მაქს. 100), რომ client-მა მილიონი სტრიქონი ვერ მოითხოვოს.

## რატომ არის ეს მნიშვნელოვანი

ეს ერთ-ერთი ყველაზე პრაქტიკული API-დიზაინის კითხვაა, რადგან თითქმის ყოველი list endpoint მას აწყდება, და არჩევანს რეალური წარმადობის შედეგები აქვს. ინტერვიუერი ჩვეულებრივ **offset-vs-cursor ტრეიდ-ოფს** ჩხრეკავს: კანდიდატს, რომელიც offset pagination-ს ყველგან იყენებს, არ უგრძვნია `OFFSET 1000000`-ის ტკივილი, რომელიც მთელ ცხრილს ასკანირებს, ან „ცვალებადი შედეგების" ბაგი, სადაც უსასრულო feed-ის მომსხურავი user-ი ერთსა და იმავე პოსტს ორჯერ ხედავს, რადგან ახალი ჩაისვა. Cursor pagination ორივეს ასწორებს request-ის ინდექსირებულ keyset ძებნად გადაქცევით, რის გამოც ყოველი მასშტაბური API (Twitter, Stripe, Slack) მას feed-ებისთვის იყენებს. ძლიერი პასუხები ასევე ახსენებენ საოპერაციო დამცავებს — filter/sort ველების whitelist-ს (არაინდექსირებული query-ებისა და injection-ის თავიდან ასაცილებლად) და `limit`-ის შეზღუდვას (database-ის დასაცავად) — რაც აშორებს იმას, ვინც ეს endpoint-ები production-ში ამუშავა, იმისგან, ვინც მხოლოდ მათ შესახებ წაიკითხა.

Pagination: offset vs cursor

Filtering და sorting

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები