Garder la prochaine action limitée
Supposons que l’application illustrée demande offline maps dans hiking avec limit=3 et page=1. Le lecteur ouvre les références et décide si un autre groupe lui serait utile. Afficher la suite doit demander la page suivante de cette même question. L’action ne doit pas explorer silencieusement toutes les pages ni changer de question en conservant les anciens résultats à l’écran.
Le repère visuel est un contrôle Afficher la suite lorsque la réponse permet une autre page. Désactivez les activations répétées pendant l’attente et laissez les références affichées accessibles. Chaque page récupérée avec succès consomme un crédit, même vide. S’arrêter avant une nouvelle demande évite cette requête future ; quitter l’écran ne garantit ni annulation ni restitution pour une requête déjà envoyée.
Conserver ensemble les paramètres de la recherche
Gardez q, subreddit, les autres filtres et limit inchangés en augmentant page. Si la personne modifie les termes ou les dates, recommencez une séquence à la page 1. Mélanger la deuxième page d’une autre question à l’ancienne liste rend l’historique trompeur, même si les deux requêtes réussissent.
L’archive utilise _doc. Ce n’est pas un tri chronologique, par pertinence ou score ; min_score filtre, il ne trie pas. Vous pouvez réordonner les données déjà récupérées pour l’affichage, mais cela n’identifie pas les meilleures ou plus récentes de toute l’archive. Les demandes successives ne garantissent pas un instantané stable.
Suivre la réponse plutôt que chercher une page vide
pagination.has_more repose sur un enregistrement supplémentaire de vérification lorsque la fenêtre le permet. Proposez la suite seulement si has_more est true et que la page est inférieure à 100. Ne continuez pas jusqu’à trouver une page vide : le service fournit déjà un signal de continuité, et chaque requête supplémentaire réussie coûte des crédits.
Lisez pagination.total avec pagination.relation. eq indique un compte exact selon la réponse ; gte une borne inférieure, pas une estimation statistique ; unknown l’absence de total fiable, éventuellement null. Pour une première réponse hypothétique affichant trois données avec total 4 et relation gte, vous pouvez indiquer au moins quatre correspondances. Vous ne pouvez pas annoncer exactement quatre.
Reconnaître la fenêtre plafonnée
Les limites sont de 100 enregistrements par requête et 100 pages. À la page 100 avec limit 100, une dernière page pleine ne laisse pas de place à la vérification supplémentaire. pagination.window_exhausted peut donc être true alors que has_more est false et relation vaut gte. À cette limite, has_more false ne prouve pas l’absence d’autres correspondances.
Une page vide après la première n’établit pas davantage un total global ; le gateway le marque inconnu dans ce cas. Expliquez la limite réelle, par exemple Fenêtre de cette recherche atteinte, plutôt que Toutes les discussions chargées. Restreindre une recherche peut organiser la suite du travail sans transformer des requêtes limitées en export exhaustif.
Fusionner avec prudence et préserver la reprise
Si un véritable identifiant est présent, votre application peut l’utiliser pour ne pas afficher deux fois une donnée dans la liste cumulée. Définissez l’identité à partir des champs reçus ; n’inventez pas un ID manquant et ne fusionnez pas des enregistrements distincts au seul motif que leurs textes se ressemblent. Une déduplication locale ne prouve pas l’exhaustivité.
L’échec de la page suivante doit laisser les anciennes données et la question intactes, avec une option explicite pour réessayer. Séparez le numéro de page en attente jusqu’au résultat et gérez les réponses désordonnées dans votre logique. L’API ne fournit pas d’endpoint à curseur ni cet état d’interface. Retrouvez sur /fr/#field-notes les exemples de chargement et de budget.
