利用者、処理、支払うアカウントを分ける
製品の利用者、内部の処理、取得料金を支払うドメインのアカウントを別々に扱います。最初の二つを結び付け、実行を許可するのは自分のバックエンドです。ブラウザーには許可した結果を返します。共通の取得キーまで渡すと、画面で設けた上限を経由しない有料要求に使われる可能性があります。
サーバーの環境変数や秘密管理の仕組みを使えば、キーをソースコードから分離できます。ただし環境変数であっても、ビルド処理でブラウザー用ファイルへ埋め込まれないか確認してください。設定の全量表示、例外報告、デバッグログも漏えい元になります。取得ヘッダーは記録から除外し、調査用には経路、引数、時刻、状態コード、ローカル処理IDなどを使います。環境変数だけで漏えいを完全に防げるとは限りません。
許可した取得要求だけを組み立てる
最初の処理ではアーカイブのホストと許可する検索経路を固定します。検証した入力からq=onboarding、subreddit=SaaS、limit=3を組み立て、外向きの要求を送る段階でキーを加えます。訪問者が渡した任意のURLへ、このヘッダーを付けて中継しないでください。処理の許可はその前に確認します。
Authorization: Bearer YOUR_API_KEYとX-API-Key: YOUR_API_KEYの両形式が使えます。どちらもこのドメインのアーカイブキーであり、Reddit OAuthトークンは使用しません。他ドメインのブランドへキーや残高を共用するものでもありません。公開サンプルと問題報告では置き換え値だけを示します。利用者に一部の検索結果を見る権限があっても、製品が使う共通キーを渡してよいことにはなりません。
再試行の判断より先に記録する
処理には内部IDと小さな試行予算を付けます。認証ヘッダーを除き、経路、引数、試行番号、結果を記録してください。例えば、ページ変更や再試行を含めて合計三回までと決められます。これは製品側のルールであり、アーカイブが利用者別のクォータや処理台帳を提供するという意味ではありません。
判断しにくい例を確認します。最初は空の成功応答で一クレジット消費し、次は応答を失うものの料金が発生している可能性があり、その再試行が成功するとさらに一クレジット必要です。応答がないだけで無料の失敗とは記録できません。上流の失敗は予約を戻しますが、ローカルの解析や保存の失敗は課金済みの成功を取り消しません。
解釈する前に応答を保存する
画面向けに変換する前に受信応答を保存します。記録は平坦で、欠けたフィールドや、取得していない記録を指すparent_id、link_idもあり得ます。まとめても完全な会話とは限りません。日付はUTCのYYYY-MM-DDでtoの日を含みます。qはtitleとtextを対象に一致するフィールド内でAND条件を適用し、min_scoreは絞り込みのみです。_docは順位や時系列ではありません。
キーの併用期間を前提にせず交換する
交換時は新しい処理を受け付けない状態を準備します。サインインしてパスワードを確認した後の再生成は、旧キーを即時に無効化します。取得を送る各プロセスを更新してから再開してください。新旧両方が動く期間に依存しない手順が必要です。新しい値の受け渡しでも閲覧者を限定し、診断への混入を避けます。
ローカルの上限で管理できるのは自分のバックエンド経由の要求だけです。漏えいしたキーの直接利用は防げません。調査では自分の試行記録とアカウントの状況を照合しますが、件数の増加だけで漏えいと断定しないでください。交換によって使用済みクレジットが戻ることもありません。リセット機能がないため、パスワードの保管も必要です。
小さな処理で経路全体を確かめる
最後に小さな処理を実行し、実際の結果を確認します。400では引数、401ではキー、402では残高、429では頻度を調べます。取得は一要求最大100記録、一クエリ最大100ページで、網羅性は保証されません。/v1/statusは静的な範囲の説明であり、アーカイブの健全性を調べません。サンプルを保存し、理由を記録して取得を止めることも、製品処理の有効な結末です。
