Buat tindakan berikutnya tetap kecil
Misalkan aplikasi pendakian ilustratif meminta offline maps di hiking dengan limit=3 dan page=1. Pembaca membuka referensi yang dikembalikan lalu menilai apakah kelompok berikutnya membantu. Tampilkan lagi seharusnya meminta halaman berikut untuk pertanyaan yang sama. Tindakan itu tidak boleh diam-diam merayapi semua halaman atau mengganti kueri sambil mempertahankan hasil lama di layar.
Petunjuk visual bagi pengguna adalah kontrol Tampilkan lagi yang muncul ketika respons mengizinkan halaman berikutnya. Cegah aktivasi berulang selama permintaan masih berjalan dan pertahankan referensi yang sudah ditampilkan. Setiap halaman yang berhasil diminta memakai satu kredit, termasuk halaman kosong. Pembaca yang berhenti sebelum meminta lagi menghindari permintaan mendatang itu; meninggalkan layar tidak menjamin pembatalan atau pengembalian biaya permintaan yang telah dikirim.
Pertahankan status permintaan sebagai satu kesatuan
Jangan ubah q, subreddit, filter pilihan lain, dan limit ketika page dinaikkan. Jika pembaca mengganti frasa atau rentang tanggal, mulai urutan hasil baru dari page 1. Mencampurkan halaman kedua dari pertanyaan berbeda ke daftar lama membuat riwayat baca menyesatkan, walaupun kedua permintaan berhasil.
Arsip memakai urutan _doc, bukan waktu, relevansi, atau skor; min_score adalah filter, bukan instruksi pengurutan. Rekaman yang sudah diambil boleh disusun ulang untuk penyajian, tetapi itu tidak menemukan kecocokan terbaru atau terbaik secara global. Tidak ada jaminan snapshot stabil pada permintaan halaman yang berulang.
Gunakan respons, bukan perulangan menebak halaman kosong
pagination.has_more didasarkan pada satu rekaman tambahan ketika jendela permintaan memungkinkan. Tawarkan kelanjutan hanya jika has_more true dan nomor halaman di bawah 100. Jangan terus mengambil sampai menemukan halaman kosong: layanan sudah menyediakan sinyal kelanjutan, dan permintaan tambahan yang berhasil memerlukan kredit.
Baca pagination.total bersama pagination.relation. eq berarti hitungan tepat menurut semantik respons itu; gte adalah batas bawah, bukan estimasi statistik; unknown tidak memberikan total terpercaya dan dapat menyertai null. Dalam respons awal hipotetis yang menampilkan tiga rekaman dengan total 4 dan relation gte, teks dapat menyatakan terindikasi setidaknya empat kecocokan. Jangan menyatakan tepat empat.
Kenali jendela yang dibatasi
Batasnya 100 rekaman per permintaan dan 100 halaman. Pada page 100 dengan limit 100, halaman akhir yang penuh tidak menyisakan ruang bagi satu rekaman tambahan. Karena itu pagination.window_exhausted dapat true saat has_more false dan relation gte. Nilai has_more false di batas ini bukan bukti bahwa tidak ada kecocokan lain dalam arsip.
Halaman kosong setelah page 1 juga tidak membuktikan total global; gateway menandai total sebagai unknown untuk kasus itu. Jelaskan batas sebenarnya kepada pembaca, misalnya Jendela pencarian ini telah tercapai, bukan Semua diskusi telah dimuat. Mempersempit kueri dapat mengatur pekerjaan lanjutan tetapi tidak mengubah permintaan terbatas menjadi ekspor menyeluruh.
Gabungkan dengan cermat dan pertahankan pemulihan kegagalan
Jika pengenal rekaman yang nyata tersedia, aplikasi dapat memakainya agar rekaman yang sama tidak muncul dua kali dalam daftar yang dikumpulkan. Tentukan aturan identitas dari field yang benar-benar diterima; jangan mengarang ID yang hilang atau menggabungkan rekaman hanya karena teksnya mirip. Deduplikasi lokal tidak membuktikan kelengkapan daftar sisanya.
Kegagalan halaman berikutnya seharusnya mempertahankan rekaman terdahulu dan kueri, dengan pilihan mencoba lagi yang jelas. Pisahkan nomor halaman yang masih tertunda sampai hasil diketahui, dan tangani respons tidak berurutan dalam logika aplikasi Anda sendiri. API tidak menyediakan endpoint kursor atau mengelola status antarmuka ini. Lihat /id/#field-notes untuk contoh pemuatan terpisah dan anggaran permintaan.
