Definieren Sie ein erreichbares Laufziel
In diesem Beispiel bedeutet Abschluss, dass ein begrenzter Stapel aus r/automation verarbeitet und sein Ergebnis protokolliert wurde. Es bedeutet nicht, dass das gesamte Archiv gelesen wurde. Beginnen Sie manuell und wählen Sie anschließend einen Zeitplan, der zur Bearbeitungskapazität Ihrer Prüfliste passt.
Erzeugen Sie eine lokale Laufkennung, speichern Sie die Suchparameter und legen Sie das Ziel ausgewählter Datensätze fest. Dies sind Angaben Ihrer Anwendung, keine zusätzlichen API-Parameter. Fehlt später ein erwarteter Fund, lässt sich anhand des Protokolls prüfen, was tatsächlich angefragt wurde. Ein unabhängiges historisches Archiv belegt keine aktuelle Reddit-Aktivität.
Übersetzen Sie die Frage in Suchparameter
Senden Sie GET https://api.apireddit.cc/v1/search?q=workflow&subreddit=automation&limit=3 mit dem Schlüssel in Authorization: Bearer oder X-API-Key. Der kleine Stapel eignet sich zur ersten Feldprüfung. kind akzeptiert post oder comment, falls Sie den Inhaltstyp einschränken möchten.
q durchsucht title und text. Mehrere Begriffe werden mit AND innerhalb eines passenden Feldes verknüpft. Ein Begriff nur im Titel und ein anderer nur im Text reichen deshalb nicht zwangsläufig für einen Treffer. from und to verwenden YYYY-MM-DD in UTC, einschließlich des Tages to. min_score entfernt Datensätze unter dem Schwellenwert, sortiert die übrigen aber nicht nach ihrer Bewertung.
Trennen Sie Inhalt und Prüfentscheidung
Speichern Sie die verfügbaren Felder id und kind und geben Sie title sowie text zur Prüfung weiter. Archivierter Inhalt ist Lesematerial und keine Handlungsanweisung für Ihren Prozess. Auswahlgrund, Prüfstatus und Laufkennung erhalten eigene lokale Felder. Prüfen Sie vor dem Anlegen, ob die Kennung bereits verarbeitet wurde.
Die Antwort ist eine Liste flacher Datensätze. Gruppieren Sie lokal über parent_id oder link_id nur dann, wenn diese Felder vorhanden und hilfreich sind. Fehlende Beziehungen bleiben unbekannt; vollständige Gespräche sind nicht zugesichert. Zum erneuten Abruf eines bestimmten Elements benötigt /v1/item dessen id. Berücksichtigen Sie diese zusätzliche Anfrage im Budget.
Protokollieren Sie den Grund für das Ende
Setzen Sie ein eigenes Seitenbudget innerhalb der erlaubten 100 Seiten und fordern Sie höchstens 100 Datensätze pro Seite an. Halten Sie die Filter während des Durchlaufs gleich. Die Dokumentreihenfolge entspricht weder Zeit noch Relevanz oder Bewertung. Der erste Treffer ist daher kein verlässlicher Marker für den neuesten bereits gelesenen Beitrag.
Lesen Sie Gesamtzahlen zusammen mit ihrer Beziehung: eq ist exakt, gte eine Untergrenze, unknown kann einen Gesamtwert null begleiten. Unterscheiden Sie eine leere Antwort von einem erreichten Seitenbudget. Datumsabschnitte strukturieren weitere Arbeit, beweisen aber weder vollständige Erfassung noch das Ausbleiben von Duplikaten.
Wiederholen Sie einen unklaren Ausgang bewusst
Bei 400 korrigieren Sie Parameter, bei 401 prüfen Sie den Schlüssel und bei 402 das Guthaben. Für 429 planen Sie eine Wartezeit und eine begrenzte Zahl von Versuchen ein. Auch ein erfolgreicher leerer Abruf kostet einen Credit. Fehler der vorgelagerten Quelle erstatten die Reservierung; ungültige Anfragen belasten das Guthaben nicht.
Geht die Antwort beim Client verloren, kann der Server bereits erfolgreich gearbeitet und einen Credit verbraucht haben. Ein erfolgreicher neuer Versuch kostet einen weiteren. Protokollieren Sie die Ungewissheit und vermeiden Sie Duplikate lokal. /v1/status ist unberechnet und liefert eine statische Dienstbeschreibung, prüft jedoch nicht den Zustand der vorgelagerten Suche. Prüfen Sie die Preise vor einer Ausweitung des Zeitplans.
