Vorab festlegen, was als Beobachtung zählt
Formulieren Sie eine prüfbare Entscheidung: Welche empfangenen r/science-Datensätze mit replication behandeln die Wiederholung einer Studie? Definieren Sie den Datensatz als Beobachtung und wählen Sie Beiträge, Kommentare oder beide. Die Abfrage liefert Textkandidaten, die lokale Prüfung ordnet sie ein. Ein Worttreffer belegt keine erfolgreiche Replikation eines wissenschaftlichen Ergebnisses.
Die API erschließt ein unabhängiges historisches Archiv ohne offizielle Reddit-Verbindung oder Live-Aktualisierungen. Historische Datensätze sind dadurch nicht unveränderlich. Vollständige Abdeckung und dieselbe Antwort bei der nächsten Abfrage sind nicht garantiert. Definieren Sie das Experiment anhand des tatsächlich empfangenen Materials. Leiten Sie daraus keine Eigenschaften der gesamten Community oder einer größeren Bevölkerung ab, ohne eine gesonderte methodische Grundlage dafür zu haben.
Legen Sie lokale Regeln für fehlende Felder, empfangene Duplikate und nicht auflösbare Referenzen fest. Trennen Sie diese Entscheidungen von den API-Parametern. Dokumentieren Sie Änderungen als Protokollversionen, statt Kriterien nach Betrachtung der Ergebnisse stillschweigend anzupassen. Ihre Aufzeichnungen sollen die Auswahl prüfbar machen. Sie bestätigen weder eine vollständige Sammlung noch ein Experiment ohne Verzerrungen und sollten auch begründete Ausschlüsse sichtbar lassen.
Die tatsächlich ausgeführte Abfrage festhalten
Beginnen Sie mit GET https://api.redditapilabs.com/v1/search?q=replication&subreddit=science&limit=3, dem Startseitenbeispiel. Speichern Sie Route und wirksame Parameter einschließlich verwendeter Standardwerte. Authentifizieren Sie den Serveraufruf mit X-API-Key: <Schlüssel> oder Authorization: Bearer <Schlüssel>, entfernen Sie aber Geheimnisse aus geteilten Dateien. Die Schlüsselseite erläutert Ausgabe vor Zahlung und Verwaltung des Zugangs; eine Kontositzung ersetzt nicht den Abrufschlüssel.
Ergänzen Sie beim Versuch mit replication crisis einen Änderungseintrag. q durchsucht title und text mit dem Operator and innerhalb des passenden Feldes, statt bloß ein Titelwort mit einem Wort im Text zusammenzuführen. Bewahren Sie die Antworten beider Formulierungen getrennt auf. Keine bildet das gesamte Vokabular wissenschaftlicher Replikation ab.
Speichern Sie jede empfangene Antwort vor Bereinigung oder Ergänzung der Felder. Notieren Sie Client-Ausführungszeit, HTTP-Status und erreichte Seitengrenzen getrennt. from und to filtern created_utc mit YYYY-MM-DD UTC einschließlich des gesamten letzten Tages, nicht den Archiveingang. Datensätze sind flach und können variieren. Vorhandene parent_id oder link_id erlauben lokale Beziehungen, ohne vollständige Unterhaltung oder Suchfilter für diese Kennungen zu garantieren.
Bedeutungen getrennt vom Original annotieren
Erstellen Sie lokal eine Annotationstabelle mit vorhandener Datensatzkennung, Kategorie und Begründung. Als erste Kategorien bieten sich Studienwiederholung, biologische Replikation und unklarer Kontext an. Das sind Ihre Annotationen, keine API-Felder. Halten Sie mehrdeutige Fälle zur Prüfung offen und bewahren Sie den Originaltext neben der bearbeiteten Fassung auf.
Sie können einen Hash der gespeicherten Datei berechnen und ihren Namen zusammen mit Code- und Abhängigkeitsversionen festhalten. Der Hash identifiziert die Bytes Ihrer Kopie; er beweist weder Echtheit des Inhalts noch Repräsentativität oder Vollständigkeit des entfernten Archivs. Bewahren Sie Original und abgeleitete Datei getrennt auf und dokumentieren Sie die verbindende Transformation. Diese Organisation leistet Ihr Team; sie ist kein von der API angebotener Speicher- oder Versionsdienst.
Beim Vergleich jeweils nur eine Größe ändern
Verwenden Sie zur Prüfung zunächst die gespeicherten Dateien und die dokumentierte Codeversion. Arbeitet Ihre Methode mit Zufall, halten Sie dessen Konfiguration und die Umgebungsbedingungen fest. Untersuchen Sie, ob Unterschiede von Daten, Regeln oder Werkzeugen stammen. Das hilft bei der Klärung von Abweichungen. Eine gespeicherte Datei garantiert für sich allein keine identischen Ergebnisse in jeder Umgebung und bestätigt keine wissenschaftliche Schlussfolgerung.
Halten Sie zunächst die gespeicherte Eingabe fest und ändern Sie nur die Annotationsregel. Beschreiben Sie, welche Entscheidungen sich weshalb ändern. Ein neuer Fernabruf bekommt einen eigenen Eintrag. Ändern sich Eingabedaten und Regeln gleichzeitig, lässt sich eine andere Kategorienhäufigkeit nicht allein einer dieser Änderungen zuschreiben.
Ein neuer Abruf ist eine weitere Beobachtung des Archivs. limit und page reichen von 1 bis 100, eine Seite pro Anfrage; _doc ist weder Chronologie noch Relevanz oder Punktestand. Lesen Sie total mit relation: eq ist exakt für die Abfrage, gte eine Untergrenze und unknown unzuverlässig, möglicherweise null. Seitenabrufe, Datumsfenster und lokale Deduplizierung beweisen keine Vollständigkeit oder Unveränderlichkeit. /v1/subreddits akzeptiert nur prefix und limit für Namen, ohne page.
Abbruchgrund und offene Fälle berichten
Schließen Sie mit Parametern, empfangenen Seiten, behaltenen Datensätzen, Ausschlüssen und ungeklärten Fällen. Nennen Sie Abbruchgrund und Regelversion der Zählung. Begrenzen Sie Aussagen auf dieses Material: unbekannte Gesamtzahl, fehlender Kontext oder eine Archivlücke beweisen nicht, dass die Community das Thema nicht diskutiert hat.
Planen Sie einen Credit pro erfolgreichem Abruf ein, auch leer oder wiederholt: $1 für 1000 Anfragen, Mindestaufladung $50. Die 100 Testcredits sind bedingt. Ungültige Anfragen belasten nicht; Fehler beim Quelldienst erstatten die Reservierung. Antwortverlust kann einen berechneten Erfolg verbergen, den ein lokaler Fehler nicht erstattet. Dokumentation und Preise erläutern den Rahmen: 400 korrigieren, bei 401 Schlüssel, bei 402 Guthaben prüfen und bei 429 Wiederholungen mit Pausen begrenzen. /v1/status prüft weder Suche noch Reproduzierbarkeit.
