JSONの見た目ではなく値を比較する
左側に元のJSON、右側に更新後のJSONを貼り付けます。ツールは両方を解析し、できあがったデータ構造を比較します。空白、字下げ、オブジェクト内のキーの並び順は、書式の違いにすぎないため、差分として表示しません。一方、値の変更、キーの追加、キーの削除は表示します。二つのAPI応答が画面上では違って見えるときに、データ自体が変わったかどうかを調べるための方法です。比較中も入力した文書はブラウザー内で扱われます。
JSONの配列は順序を持つ一覧です。要素はそれぞれの添字で比較されるため、値を別の位置へ移すと複数の差分が生じる場合があります。手順や順位の並びでは位置に意味があるので、これは意図した動作です。各項目に安定したIDがあり、順序を無視できるデータなら、まず目的に合った規則で項目を揃えるか並べ替えてください。添字のずれを、すべて独立した編集だと決め付けないことが大切です。
差分の場所を示すパスを読む
各差分にはJSON Pointerに似たパスが付きます。最上位にある名前というキーは/名前、役割という配列の二番目の要素は/役割/1です。出力は追加、削除、変更を区別します。キーに特殊な記号がある場合、スラッシュは~1、チルダは~0に置き換えられます。この表記により、入れ子になった文書全体を目で探さずに、変化した正確な位置を見つけられます。
用意された例を試してください。元のオブジェクトには名前としてエイダと役割の管理者があり、更新後にはグレースという名前と追加の編集者があります。結果には/名前の変更と/役割/1の追加が現れるはずです。字下げだけを変えても構造上の差分は出ません。しかし文字列の"1"を数値の1に置き換えると、見た目が似ていてもJSONでは異なる型なので、本当の変更として報告されます。
API応答や設定の確認に使う
デプロイ前後のサービスの応答、設定ファイルの二つの版、またはテストで期待した出力と実際の出力を比べられます。重要なパスを問題報告に記載すれば、同僚が同じ変化を再現しやすくなります。ローカルでの処理は文書を外部サービスへ送らないという利点があります。ただし、秘密の値をチケットや結果のスクリーンショットで共有するかどうかは別の判断として慎重に考えてください。
最初に両方の文書が有効なJSONか確認します。標準のJSONでは、末尾の余分なカンマやコメントは使えません。構文の問題を直してから比較を実行し、最初に変わったパスを見て、アプリケーションにとって重要な変更か判断します。配列の添字が大量にずれている場合は、各要素が個別に変更されたと考える前に、並び順の変更が原因か調べてください。
結果の限界を正しく理解する
この比較は構造を調べるもので、スキーマの検証やアプリケーション固有の意味の判定ではありません。異なるURLが同じ資源を指すか、フィールド名の変更が計画された移行なのかは判断できません。非常に大きな入力には制限があり、画面には最初の500件までの差分を示します。もっと大きな文書を完全に監査する必要がある場合は、元のデータを保管して別の手段も用意してください。
通常のJSON解析では、オブジェクトの同じキーが重複したときの扱いはパーサーの動作に従います。重複キーを含む曖昧な文書の調査には、この表示は向いていません。また数値はJavaScriptの表現を使用するため、安全に表せる範囲を超える整数は専用の正確な解析器が必要です。一般的なAPIのデータや設定ファイルで、これらの範囲内に収まる値を調べる用途に適しています。