Richten Sie die erste Anfrage nach der Frage der lesenden Person aus

Das eigene Backend zwischen App und Archiv schalten

Für die beispielhafte Wanderfunktion sendet der mobile oder Web-Client die Formulierung offline maps an Ihr eigenes Backend. Dieses validiert die Anfrage, setzt die Grenzen Ihrer App durch und ruft das Archiv mit einem gespeicherten Dienstschlüssel auf. Geben Sie nur Felder zurück, die der Lesebildschirm benötigt. Das Beispiel ist ein Ausgangspunkt für den Entwurf, kein Nachweis, dass dieser Mandant bereits Wanderdatensätze geliefert hat.

Verwenden Sie GET https://api.redditapp.com/v1/search?q=offline%20maps&subreddit=hiking&limit=3&page=1. Senden Sie vom Backend entweder X-API-Key: YOUR_SAVED_KEY oder Authorization: Bearer YOUR_SAVED_KEY als Header. Zugangsdaten gehören nicht in URLs, Client-Bundles oder öffentliche Protokolle. Das Sitzungscookie der Kontoseite ersetzt die Authentifizierung für Abrufanfragen nicht.

Nur tatsächlich unterstützte Filter verwenden

Die Suche akzeptiert q, subreddit, author, kind, from, to, min_score, limit und page. q verknüpft Treffer über title und text mit AND; daraus folgt weder eine exakte Phrasensuche noch semantisches Matching. kind akzeptiert post oder comment. Subreddit und Autor werden anhand exakter Feldwerte gefiltert. min_score filtert Datensätze, sortiert sie aber nicht.

Geben Sie from und to als UTC-Daten im Format YYYY-MM-DD an. Das Datum to schließt den gesamten betreffenden UTC-Tag ein. Zum Beispiel definieren from=2025-01-01 und to=2025-12-31 einen Zeitraum, ohne eine Datumssortierung anzufordern. Senden Sie keine ISO-Datetime-Zeichenfolgen, beliebige Query-DSL, einen Parameter sort oder Filter für parent_id/link_id. Nicht unterstützte Parameter werden abgewiesen.

Den Endpunkt nach der Aufgabe auswählen

GET /v1/posts und GET /v1/comments beschränken die Datensatzart und akzeptieren die Suchfilter; eine id ist nicht erforderlich. GET /v1/item?id=RECORD_ID sucht einen verfügbaren Datensatz anhand seiner id. GET /v1/subreddits?prefix=hik&limit=3 liefert eine begrenzte Subreddit-Aggregation; deren Zählwerte garantieren keine globale Exaktheit.

GET /v1/status ist öffentlich und kostenlos. Die Antwort enthält einen statischen Hinweis zum historischen Archiv und zeigt, dass der HTTP-Handler antwortet. Sie fragt weder das Suchbackend ab noch belegt sie Inhaltsabdeckung oder misst den Zustand des Archivs. Keiner dieser Endpunkte bietet Veröffentlichen, Abstimmen, Nachrichten, Kontolesezeichen oder einen vollständigen Unterhaltungsbaum.

Vor dem Nachladen die Paginierungsfelder lesen

Abrufantworten enthalten data, pagination und credits. Die Datensätze in data sind flache Quellobjekte aus dem vorgelagerten System; ausgewählte Felder wie Titel, Autor, Datum oder Permalink können fehlen. Das Archiv verwendet _doc-Reihenfolge, keine chronologische, Relevanz- oder Bewertungssortierung. Eine lokale Sortierung kann die abgerufene Teilmenge neu ordnen, sie aber nicht zur global neuesten oder höchstbewerteten Teilmenge machen.

Behalten Sie beim Erhöhen von pagination.page dieselben Filter und dasselbe limit bei. pagination.has_more nutzt, sofern verfügbar, einen zusätzlich vorausgelesenen Datensatz. Ist der Wert false, bieten Sie keine automatische Folgeanfrage an. pagination.window_exhausted kennzeichnet den begrenzten Fall der letzten Seite; sein Erreichen beweist nicht, dass sämtliches passendes Archivmaterial abgerufen wurde.

Die Grenzen sind 1–100 Datensätze und Seiten 1–100. Lesen Sie pagination.total immer zusammen mit pagination.relation: eq ist im Rahmen der Zählsemantik der Antwort exakt, gte ist eine Untergrenze, und unknown liefert keine zuverlässige Gesamtzahl; diese kann null sein. Eine leere Seite nach Seite eins kann keine Gesamtzahl belegen. Eine volle Seite 100 bei limit 100 hat keinen Platz für einen zusätzlichen vorausgelesenen Datensatz und liefert eine Untergrenze; an der Seitengrenze ist has_more false. Bei der Subreddit-Aggregation ist total unbekannt, und pagination.truncated kennzeichnet ausgelassene Aggregationsgruppen.

Abrechnung und Fehler ausdrücklich behandeln

Ein erfolgreicher Abruf kostet einen Credit, auch bei einem leeren data-Array. Validieren Sie Eingaben vor dem Senden und rufen Sie keine Seiten nur für die Animation einer Ladeanzeige ab. HTTP 400 bedeutet ungültige Eingabe, 401 einen fehlenden oder ungültigen Dienstschlüssel, 402 unzureichendes Guthaben und 429 eine Ratenbegrenzung. Diese abgewiesenen Anfragen reservieren keinen Abruf-Credit.

Ein Fehlschlag beim vorgelagerten Dienst wird als HTTP 502 gemeldet und gibt den reservierten Credit frei oder meldet eine noch ausstehende Erstattungsabstimmung. Geht die Antwort an der Grenze zu Ihrer App verloren, bleibt das Ergebnis ungewiss; nehmen Sie nicht an, die Anfrage sei kostenlos gewesen. Erhalten Sie den Abfragezustand, beachten Sie Retry-After und lassen Sie die nutzende Person gegebenenfalls bewusst erneut versuchen. Schlüssel- und Guthabenverwaltung sind Aufgaben des Betreibers, nicht der wandernden Person.

Die Antwort in einen ehrlichen Lesebildschirm übertragen

Maskieren Sie Datensatztexte vor der Darstellung. Erhalten Sie die Quellenidentität und, sofern vorhanden, einen Quellenlink, kennzeichnen Sie fehlende Daten als unbekannt und unterscheiden Sie den Erstellungszeitpunkt des Datensatzes vom Abrufzeitpunkt Ihrer App. Vorhandene Eltern- und Linkkennungen können eine lokale Gruppierung unterstützen, liefern aber keine fehlenden Vorfahren.

Zustände der Oberfläche entwickelt die vorgeschlagenen Lade-, Leer- und Fehlermeldungen. Die Praxisnotizen im App-Rundgang behandeln Karten, lokal gespeicherte Verweise und das Budgetieren von Anfragen. Schlüssel und Guthaben enthält Kontoeinrichtung und Preise. Prüfen und testen Sie Ihre eigene Umsetzung; diese Beispiele belegen weder eine laufende Funktion noch aktuelle Ratschläge zu Wanderwegen.