Die nächste Aktion klein halten
Angenommen, die beispielhafte Wander-App sucht in hiking nach offline maps mit limit=3 und page=1. Eine lesende Person öffnet die zurückgegebenen Verweise und entscheidet, ob eine weitere Gruppe hilft. „Mehr anzeigen“ sollte die nächste Seite derselben Frage anfordern. Es sollte weder stillschweigend alle Seiten durchlaufen noch die Abfrage ändern, während alte Ergebnisse sichtbar bleiben.
Als sichtbares Signal dient eine Schaltfläche zum Nachladen, die erscheint, wenn die Antwort eine weitere Seite erlaubt. Verhindern Sie wiederholtes Aktivieren während dieser Anfrage und halten Sie bereits angezeigte Verweise verfügbar. Jede erfolgreiche Seitenanfrage verbraucht einen Credit, auch für eine leere Seite. Wer vorher aufhört, vermeidet diese künftige Anfrage; das Verlassen der Ansicht garantiert aber weder Abbruch noch Erstattung bereits gesendeter Anfragen.
Den Anfragezustand zusammenhalten
Lassen Sie q, subreddit, weitere gewählte Filter und limit beim Erhöhen von page unverändert. Ändert die Person Formulierung oder Zeitraum, beginnen Sie bei page 1 eine neue Ergebnisfolge. Eine zweite Seite zu einer anderen Frage mit der alten Liste zu mischen verfälscht den Leseverlauf, selbst wenn beide Anfragen erfolgreich sind.
Das Archiv verwendet _doc-Reihenfolge, keine chronologische, Relevanz- oder Bewertungssortierung; min_score ist ein Filter und keine Sortieranweisung. Sie können die bereits abgerufenen Datensätze für die Darstellung umordnen, identifizieren damit aber nicht die global neuesten oder besten Treffer. Wiederholte Seitenanfragen bringen keine Garantie einer stabilen Momentaufnahme mit.
Die Antwort nutzen statt leere Seiten zu erraten
pagination.has_more beruht auf einem zusätzlich vorausgelesenen Datensatz, sofern das Anfragefenster dies erlaubt. Bieten Sie die nächste Aktion nur bei has_more true und einer Seitennummer unter 100 an. Rufen Sie nicht so lange ab, bis eine leere Seite erscheint: Der Dienst liefert bereits ein Fortsetzungssignal, und zusätzliche erfolgreiche Anfragen kosten Credits.
Lesen Sie pagination.total zusammen mit pagination.relation. eq bedeutet eine exakte Zahl im Rahmen der Zählsemantik dieser Antwort; gte ist eine Untergrenze, keine statistische Schätzung; unknown liefert keine verlässliche Gesamtzahl und kann zusammen mit null auftreten. Zeigt eine hypothetische erste Antwort drei Datensätze, total 4 und relation gte, könnte die Formulierung auf eine Gesamtzahl von mindestens vier Treffern hinweisen. Sie darf nicht von genau vier sprechen.
Das begrenzte Fenster erkennen
Die Grenzen sind 100 Datensätze pro Anfrage und 100 Seiten. Auf page 100 bei limit 100 lässt eine volle letzte Seite keinen Platz für einen zusätzlichen vorausgelesenen Datensatz. pagination.window_exhausted kann deshalb true sein, während has_more false und relation gte sind. Ein falsches has_more an dieser Grenze beweist nicht, dass das Archiv keine weiteren Treffer enthält.
Auch eine leere Seite nach page 1 kann keine globale Gesamtzahl belegen; das Gateway kennzeichnet sie in diesem Fall als unbekannt. Beschreiben Sie die tatsächliche Grenze, etwa Suchfenster erreicht, statt Alle Diskussionen geladen. Eine engere Abfrage kann weitere Arbeit strukturieren, macht begrenzte Abrufe aber nicht zu einem erschöpfenden Export.
Sorgfältig zusammenführen und Fehler behebbar halten
Ist eine echte Datensatzkennung vorhanden, kann Ihre App damit doppelte Anzeige im eigenen gesammelten Ergebnis vermeiden. Wählen Sie Identitätsregeln anhand tatsächlich erhaltener Felder; erfinden Sie keine fehlende ID und verschmelzen Sie unterschiedliche Datensätze nicht allein wegen ähnlichen Texts. Lokale Deduplizierung beweist keine Vollständigkeit der verbleibenden Liste.
Eine fehlgeschlagene Folgeseitenanfrage sollte frühere Datensätze und Abfrage unverändert lassen und eine ausdrückliche Wiederholungsentscheidung anbieten. Halten Sie die ausstehende Seitennummer bis zum bekannten Ergebnis getrennt und behandeln Sie falsch gereihte Antworten in Ihrer eigenen Anwendungslogik. Die API bietet weder einen Cursor-Endpunkt noch die Verwaltung dieses Oberflächenzustands. Unter /de/#field-notes finden Sie Beispiele getrennter Ladezustände und Anfragebudgetierung.
