JSONの削除フィールドを検出する

削除フィールドは追加の逆で、元のJSONドキュメントには存在するが更新版には存在しないキーです。削除の検出は、API、設定ファイル、データスキーマにおいて破壊的変更を示すことが多いため重要です。

削除検出の仕組み:

diffアルゴリズムは、左側（元の）ドキュメントのすべてのキーを反復処理します。右側（更新された）ドキュメントに対応するエントリがない各キーについて、「削除」操作が記録されます。完全なJSONパスが保持されるため、どのフィールドが削除されたかを正確に追跡できます。

// 変更前
{
  "id": 42,
  "name": "Widget",
  "description": "A useful widget",
  "deprecated": false,
  "legacy_code": "WDG-001"
}

// 変更後
{
  "id": 42,
  "name": "Widget",
  "description": "A useful widget"
}

diffは2つの削除を報告します：deprecated と legacy_code。両方のフィールドとその値が完全になくなっています。

RFC 6902での表現:

JSON Patch形式では、削除に "op": "remove" と削除場所を指す "path" を使用します。追加とは異なり、操作はそのパスに存在するものを単に削除するため、"value" は不要です。

後方互換性への影響:

• APIレスポンス: APIレスポンスからフィールドを削除すると、そのフィールドに依存するクライアントが壊れる可能性があります。APIバージョニングガイドラインでは、削除前に非推奨期間を設けることを推奨しています。
• 設定ファイル: 設定キーを削除すると、アプリケーションがデフォルト値にフォールバックするか、最悪の場合、キーが必須である場合にエラーをスローする可能性があります。
• データベースマイグレーション: データベーススキーマのカラム削除も同様です。JSON diffは、マイグレーション実行前にその内容をプレビューするのに役立ちます。

よくある落とし穴:

フィールドを null に設定することは、フィールドを削除することとは異なります。null 値を持つフィールドはJSON構造内にまだ存在しており、これは値の変更であって削除ではありません。diffツールはこの2つのシナリオを区別し、混同するとマイグレーションスクリプトの誤りにつながる可能性があります。