Chrome拡張でサイトの情報を扱うとき、最初から特定のAPIやDOM構造に決め打ちすると、認証方式や画面更新の違いで作り直しになることがあります。実装前に対象サイトを実際に開き、候補となる取得経路を小さく比較します。
候補を順に比較する
画面上に表示された情報だけで足りるなら、ページのDOMを読む方法が単純です。サーバーから取得したHTMLを解析できる場合は、fetchとDOMParserを検討します。ただし、ログインCookie、CORS、CSRF、相対URL、JavaScript描画後の差を実機で確かめます。
画面HTMLに初期データが埋め込まれていれば、そのJSONが利用できる場合があります。SPAが独自の通信を行う場合は、DevToolsのNetworkで通信形式を調査します。ページ側のJavaScriptコンテキストが必要なら、background tabやMAIN worldでの実行を候補にします。内部APIは将来も安定して使える保証がない点に注意します。
取得結果を必要最小限にして調べる
Consoleで確認する値は、件数、キー名、型、先頭数文字など必要最小限にします。認証ヘッダー、Cookie、CSRF値、本文、案件名など識別につながる文字列をログや共有資料へ出さないでください。調査用コードには値を伏せる処理を先に入れます。
未読だけなどのフィルター済み一覧は、状態を変更した途端に対象から消える場合があります。取得時点の識別子と状態を記録し、相対時刻を使う場合は取得日時も保持します。
まとめ
DOM、HTML取得、埋め込みJSON、内部APIを一律に優劣づけず、対象サイトで必要な情報を安全に取得できる最小の経路を選びます。調査時点の観測と、公開仕様として保証される事項は区別して記録しましょう。