Rendere piccola l’azione successiva
Supponi che l’app illustrativa cerchi offline maps in hiking con limit=3 e page=1. Il lettore apre i riferimenti restituiti e decide se un altro gruppo sia utile. Mostra altro dovrebbe richiedere la pagina seguente per la stessa domanda, non avviare silenziosamente la scansione di tutte le pagine o cambiare la query mantenendo i vecchi risultati visibili.
Il segnale visivo è un controllo Mostra altro che compare quando la risposta consente un’altra pagina. Disabilita attivazioni ripetute durante l’attesa e conserva i riferimenti già mostrati. Ogni richiesta di pagina riuscita consuma un credito, anche con pagina vuota. Fermarsi prima di chiederne un’altra evita quella richiesta futura; lasciare la schermata non garantisce annullamento o rimborso di una già inviata.
Tenere unito lo stato della richiesta
Mantieni q, subreddit, gli altri filtri scelti e limit invariati mentre incrementi page. Se il lettore cambia frase o intervallo di date, avvia una nuova sequenza da page 1. Mescolare nella lista precedente una seconda pagina relativa a un’altra domanda rende fuorviante la cronologia di lettura, anche se entrambe le richieste riescono.
L’archivio usa l’ordine _doc, non quello cronologico, di rilevanza o punteggio; min_score è un filtro, non un’istruzione di ordinamento. Puoi riorganizzare i record già caricati per mostrarli, ma non identifichi così le corrispondenze globalmente più recenti o migliori. Le richieste ripetute di pagine non hanno una garanzia di snapshot stabile.
Usare la risposta, non cercare a tentoni una pagina vuota
pagination.has_more si basa su un record aggiuntivo di controllo quando la finestra lo consente. Offri l’azione successiva solo se has_more è true e page è inferiore a 100. Non continuare finché appare una pagina vuota: il servizio espone già un segnale di continuazione e altre richieste riuscite costano crediti.
Leggi pagination.total insieme a pagination.relation. eq significa conteggio esatto secondo la semantica di quella risposta; gte è un limite inferiore, non una stima statistica; unknown non fornisce un totale affidabile e può accompagnare null. In una prima risposta ipotetica con tre record, total 4 e relation gte, il testo potrebbe indicare almeno quattro corrispondenze. Non deve dire che sono esattamente quattro.
Riconoscere la finestra massima
I limiti sono 100 record per richiesta e 100 pagine. A page 100 con limit 100, una pagina finale piena non lascia posto a un record aggiuntivo di controllo. pagination.window_exhausted può quindi essere true mentre has_more è false e relation è gte. A questo confine, has_more false non prova che nell’archivio non esistano altre corrispondenze.
Neppure una pagina vuota oltre page 1 dimostra un totale globale; in quel caso il gateway indica il totale come sconosciuto. Descrivi il limite effettivo, per esempio Finestra di ricerca raggiunta, invece di Tutte le discussioni caricate. Restringere la query può organizzare altro lavoro, ma non trasforma richieste limitate in un’esportazione esaustiva.
Unire con attenzione e rendere recuperabili i problemi
Se è presente un identificatore reale del record, l’app può usarlo per evitare di mostrare due volte lo stesso record nella propria lista accumulata. Scegli regole d’identità dai campi effettivamente ricevuti: non inventare un ID mancante e non unire record diversi solo perché il testo si somiglia. La deduplicazione locale non dimostra che la lista restante sia completa.
Una richiesta della pagina successiva fallita dovrebbe lasciare intatti record precedenti e query, con una scelta esplicita di riprovare. Tieni separato il numero di pagina in sospeso finché non conosci l’esito e gestisci risposte fuori ordine nella logica della tua applicazione. L’API non offre un endpoint a cursore e non gestisce questo stato dell’interfaccia. Torna a /it/#field-notes per esempi di caricamenti separati e budget delle richieste.
