Endpunkte und erlaubte Filter Seiten, Gesamtzahlen und flache Datensätze Fehler behandeln und Kosten zuordnen Endpunkte und erlaubte Filter Senden Sie Leseanfragen mit GET und dem Schlüssel dieser Domain in Authorization: Bearer oder X-API-Key. /v1/search durchsucht Inhalte. /v1/posts legt den Typ post fest, /v1/comments den Typ comment; diese beiden Endpunkte verlangen keine id. /v1/item benötigt dagegen id für einen einzelnen Eintrag. Allgemeine Suchfilter gehören nicht zu dieser Einzelabfrage. Verwenden Sie jeweils die Parameter des gewählten Endpunkts.
Für Inhaltssuchen stehen q, subreddit, author, kind, from, to, min_score, limit und page zur Verfügung. kind akzeptiert post oder comment. from und to erwarten YYYY-MM-DD und beziehen sich auf created_utc in UTC; der Endtag wird vollständig eingeschlossen. min_score filtert anhand eines Mindestwerts und steuert keine Sortierung. parent_id und link_id sind keine unterstützten Suchfilter, selbst wenn sie in Datensätzen vorkommen.
/v1/subreddits unterstützt prefix und limit für die Suche nach Community-Namen. page und die Datumsfilter der Inhaltssuche sind dort nicht vorgesehen. Die dortigen Zählwerte ergeben kein exaktes Gesamtinventar des Archivs. /v1/status ist öffentlich und wird nicht berechnet. Seine statische Auskunft zeigt, dass der HTTP-Server antwortet; sie prüft weder das Suchsystem noch die Verfügbarkeit bestimmter Datensätze.
Seiten, Gesamtzahlen und flache Datensätze Bei Inhaltssuchen liegen limit und page jeweils zwischen 1 und 100. Die interne Reihenfolge _doc ist keine zeitliche, nach Relevanz geordnete oder nach Punktzahl sortierte Folge. Wer alle erlaubten Seiten durchläuft, hat damit keine vollständige Erfassung nachgewiesen. Auch das Aufteilen nach Datumsbereichen schafft keine Garantie, dass sämtliche passenden Einträge vorhanden oder erreichbar sind. Beschreiben Sie den Umfang Ihres Abrufs entsprechend begrenzt.
Lesen Sie die Gesamtzahl zusammen mit ihrer Relation. eq bedeutet exakt, gte eine Untergrenze und unknown, dass keine verlässliche Gesamtzahl vorliegt; der Wert kann dann null sein. Ein unbekannter Wert ist nicht gleich null Treffer. Speichern Sie diese Angaben zusammen mit den Suchparametern, damit die Zahl der tatsächlich übernommenen Datensätze nicht mit einer vermeintlichen Größe des gesamten Archivs verwechselt wird.
Die Datensätze sind flach und bilden keine serverseitig zusammengesetzten Gesprächsbäume. Prüfen Sie vorhandene Eigenschaften und ihre Typen, bevor Sie Zielspalten befüllen. Verweise über parent_id oder link_id können lokal verarbeitet werden; ein passender Elternknoten muss dennoch nicht enthalten sein. Zusätzliche Anforderungen Ihres Ziels, etwa ein Pflichtfeld, sind lokale Validierungsregeln und keine Erweiterung der API-Zusagen.
Fehler behandeln und Kosten zuordnen HTTP 400 steht für eine ungültige Anfrage; kontrollieren Sie Parameternamen, Werte und Formate. HTTP 401 meldet einen fehlenden oder ungültigen Schlüssel, HTTP 402 zu wenig Guthaben und HTTP 429 eine überschrittene Anfragerate. Beheben Sie die jeweilige Ursache vor weiteren Versuchen. Prüfen Sie bei 401 insbesondere, ob Sie den Schlüssel der richtigen Domain verwenden, statt sofort einen neuen Schlüssel zu erzeugen.
Ein erfolgreicher Abruf kostet einen Credit, auch bei leerem Ergebnis. Abgewiesene Anfragen verbrauchen keine Credits, und bei einem Fehler der Datenquelle wird die Reservierung zurückgegeben. Geht die Antwort erst beim Client verloren, kann auf dem Server trotzdem ein berechneter Erfolg vorliegen. Ein erfolgreicher Wiederholungsabruf kostet erneut einen Credit. Fehler in Ihrer lokalen Typprüfung oder Speicherung ändern diese Abrechnung nicht.
