確認に使う実際の応答を残す
最初の要求はhttps://api.redditextract.com/v1/search?q=index&subreddit=PostgreSQL&limit=3です。PostgreSQLでindexを検索し、最大三件を要求します。日時条件は含まれません。必要ならfromとtoでUTCのYYYY-MM-DD日付を指定し、toが最終日全体を含むことに注意します。認証はサーバー上のBearerまたはX-API-Keyで行い、実キーを共有用の設定に残しません。
元の項目と出力列の対応を書く
プログラムを動かさなくても読める対応表を作ります。出力列ごとに、観察した元の項目、許容する型、欠損時の処理、コピーか派生値かを書いてください。content_sourceをtitleまたはtextというローカルの印にし、source_pageを自分の要求記録から付ける方法もあります。これらは自分の出力名であり、APIが返す追加項目ではありません。
取得結果の項目を一つずつ調べます。記録の種類が違えば同じ列が全部そろうとは限りません。APIはフラットな記録を返し、出力先の固定スキーマを生成しません。欲しい項目がない場合は、補完したように見せず、その状態を出力規則に含めます。少数例だけで全アーカイブの型や項目の存在を確定しないでください。
各出力列について元の項目名、対象の型、必須か任意か、失敗時の扱いを書きます。存在しない項目、null、空文字列、数値のゼロを別々に定義します。識別子は表記を保ち、計算用の数値へ不用意に変換しないでください。日時は型と単位を確認してから変換します。出力先に必要な情報でも、元の応答にない値を推測で作ってはいけません。
タイトルと本文のどちらを使ったか残す
qはtitleとtextを検索します。検索語が複数ある場合は、一致する一つの項目の中で各語がそろう必要があり、二つの項目に語を分散させても足りません。q=indexでも両方を別々に確認して内容を選びます。textがなければ欠損を残すか、出所を記録した明示的なtitle代用ルールを使い、元の本文とは区別してください。
型変換の前に欠損状態を確かめる
文字列の空白除去や表記統一などはローカル処理で、意味が変わる場合があります。元の値と変換後の値を別に残す方法もあります。型が混ざる場合は失敗を保留記録へ分け、理由と規則の版を記録します。parent_idとlink_idがあれば任意の関係整理はできますが、検索引数ではなく、存在しない親や会話を復元することもできません。
受け取った各レコードの処理結果を説明する
合成テストであると明記し、タイトルだけ、本文だけ、両方あり、明示的なnull、両項目なしを試します。出力値と出所の印を両方確認し、除外した記録は変更前のオブジェクトと理由を残してください。一記録から最大一行を作る変換なら、採用数と除外数の合計で受信した記録を説明できます。この数はアーカイブ全体の件数ではありません。
次のページが必要な理由を決める
保存済み応答に新しい規則を適用すれば、取得をやり直さず変換を比較できます。取得条件、UTC取得日時、元の応答、変換規則、出力件数を別に管理してください。別の日に同じクエリを実行しても同じ結果は保証されません。_doc文書順は時系列、関連度、スコア順ではなく、min_scoreも順序を変えない最低点の条件です。
一要求100件、一クエリ100ページの上限は完全取得を意味しません。eqは正確な総数、gteは下限、unknownは不明で、総数がnullの場合もあります。ページ反復や日付分割で全件取得は証明できません。成功した空の要求も一クレジットで、成功した取得1,000回の費用は$1です。上流失敗では予約分が戻りますが、応答喪失後の成功した再試行は別料金です。/v1/statusは変換処理や資料の存在を検査しません。
