Bir mağazada 20.000 ürün varsa API bunları tek yanıtta göndermez. Ürünler sayfalara bölünür; yazılım birinci sayfayı alır, sonra ikinciyi ister ve son sayfaya kadar devam eder. Bu sayede yanıtlar küçük kalır, sunucu ve ağ yükü azalır.
Yaygın yöntemler
| Yöntem | Parametreler | Mantık |
|---|---|---|
| Sayfa numarası | page, size | "3. sayfayı, sayfa başı 100 kayıtla ver" |
| Offset | offset, limit | "İlk 200 kaydı atla, sonraki 100'ü ver" |
| İmleç (cursor) | after, first gibi | "Şu kayıttan sonrasını ver"; GraphQL API'lerinde yaygın |
Gerçek sınırlar
- Hepsiburada: Listing ve OMS servisleri offset ile limit, MPOP servisi page ile size kullanır. MPOP mağaza ürün listesi sayfa başına en fazla 100 kayıt döndürür. Ayrıntı: Hepsiburada istek sınırları ve sayfalama.
- Trendyol cari hesap ekstresi: Satış ve diğer finansal hareketlerde size 500 ya da 1000 olabilir; ödeme emirleri servisinde sayfa başına en fazla 10 kayıt döner.
- N11 SOAP soru servisi: Sayfa bilgisi pagingData bloğunda currentPage ve pageSize ile verilir.
Sık hatalar
- Yalnız ilk sayfayı okumak: En yaygın hatadır. Yazılım "ürün bulunamadı" der, oysa ürün ikinci sayfadadır.
- Sayfa numarasının sıfırdan mı birden mi başladığını karıştırmak: Platforma göre değişir; ilk sayfa atlanabilir.
- Değişen veride sayfa kayması: Siz sayfaları gezerken yeni kayıt eklenirse bir kayıt iki kez gelebilir ya da atlanabilir. Tarih filtresi ve sabit sıralama bu riski azaltır.
- Sayfa sayısını sınırsız döngüye bırakmak: Toplam sayfa sayısını ya da boş sayfayı durma koşulu yapın.
İstek sınırıyla ilişkisi
Her sayfa ayrı bir istektir. 20.000 ürünü sayfa başı 100 kayıtla okumak 200 istek demektir. Bu yüzden büyük kataloglarda sayfa boyutunu platformun izin verdiği en yüksek değere çekmek ve istek sınırına dikkat etmek gerekir. Sık tekrar eden sorgularda yalnız değişen kayıtları çekmek için tarih filtresi kullanın; bkz. polling.