कोई भी endpoint जो एक collection लौटाता है उसे परिणामों को सीमित और आकार देना पड़ता है। तीन चिंताएँ — pagination, filtering, sorting — सभी query string में रहती हैं।
Offset (page-आधारित) — ?page=3&limit=20 या ?offset=40&limit=20।
GET /orders?offset=40&limit=20 HTTP/1.1
सरल और किसी भी page पर कूदने की अनुमति देता है, पर बड़े पैमाने पर इसकी दो समस्याएँ हैं: OFFSET 100000 database को 100k rows scan करके फेंकने पर मजबूर करता है (धीमा), और अगर requests के बीच rows insert/delete होती हैं, तो items खिसक जाते हैं और आपको duplicates या skips दिखते हैं।
Cursor (keyset) — client देखे गए अंतिम item की ओर एक opaque pointer भेजता है।
GET /orders?limit=20&cursor=eyJpZCI6MTAyMH0 HTTP/1.1
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 में अनुवादित करता है — एक indexed lookup जो किसी भी गहराई पर तेज़ रहता है और inserts के विरुद्ध स्थिर है। Trade-off: "page 500" तक कोई random access नहीं।
Offset → small datasets, admin UIs, "jump to page N"
Cursor → large/infinite feeds, real-time data, mobile scroll
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
status=shipped)। अनुमत fields को whitelist करें।sort param के साथ Sort करें; एक - prefix का मतलब descending (-created_at) है। स्थिर ordering के लिए multi-key का समर्थन करें।limit को सीमित करें (उदा. अधिकतम 100) ताकि कोई client दस लाख rows न माँग सके।यह सबसे व्यावहारिक API-design सवालों में से एक है क्योंकि लगभग हर list endpoint इससे टकराता है, और choice के असली performance परिणाम होते हैं। Interviewer आमतौर पर offset-बनाम-cursor trade-off टटोलता है: एक उम्मीदवार जो हर जगह offset pagination की ओर बढ़ता है, उसने OFFSET 1000000 के table scan करने का दर्द नहीं झेला, या "shifting results" bug जहाँ एक infinite feed scroll कर रहा user वही post दो बार देखता है क्योंकि एक नया insert हो गया। Cursor pagination दोनों को query को एक indexed keyset lookup में बदलकर ठीक करती है, यही कारण है कि हर बड़े पैमाने का API (Twitter, Stripe, Slack) feeds के लिए इसे इस्तेमाल करता है। मज़बूत जवाब operational guardrails का भी उल्लेख करते हैं — filter/sort fields को whitelist करना (unindexed queries और injection से बचने के लिए) और limit को सीमित करना (database की रक्षा के लिए) — जो किसी ऐसे व्यक्ति को अलग करता है जिसने ये endpoints production में चलाए हैं उससे जिसने केवल उनके बारे में पढ़ा है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें