search

Found

info 概要

RFC 6902 の JSON Patch 6 操作 (add/remove/replace/move/copy/test) を順次適用。適用後 JSON と操作トレースを表示、失敗時は op[i] 位置と原因を明示

📘 使い方

  1. ターゲット JSON 文書を左の入力欄に貼り付ける
  2. RFC 6902 の操作配列を右の入力欄に貼り付ける
  3. ステータスと適用後 JSON、操作トレースを確認する

JSON Patch (RFC 6902) 適用シミュレータ

パッチを適用する元の JSON 文書。

RFC 6902 の操作オブジェクトを並べた配列 (例: [{"op":"add","path":"/x","value":1}])。

ステータス —
 
— 
—
コピーしました!

    ※ RFC 6902 (JSON Patch) と RFC 6901 (JSON Pointer) に準拠して操作を順次適用します。

    ※ 1 つの操作が失敗するとパッチ全体が失敗扱いになり、結果は元の文書が返ります。

    grid_view 関連ツール

    Article

    JSON Patch (RFC 6902) 適用シミュレータ｜6 操作を順に適用して結果を確認

    RFC 6902 の JSON Patch を、サーバーを立てずに手元で試せる検証ツール。add / remove / replace / move / copy / test の 6 操作を上から順に適用し、適用後の JSON 文書と「どの操作で何が起きたか」の人間可読トレースを並べて表示。1 操作でも失敗すれば全体を失敗扱いにして元文書を返す atomic（全部成功か全部失敗か）動作も再現。

    💡 このツールについて

    PATCH エンドポイントを設計・実装するとき、「この操作配列を投げたら文書がどう変わるか」を確かめたい場面は多い。だが実際の API サーバーを起動し、リクエストを組み立て、レスポンスを見る、という往復は重い。とくに move と copy の挙動、test 操作の成否、配列末尾追加 - の扱いは、仕様を読んだだけでは確信が持てない。

    このツールは、その確認をブラウザ内だけで完結させる。ターゲット文書と操作配列を貼れば、JSON Pointer（RFC 6901）による path 解決まで含めて RFC 6902 どおりに適用し、結果を整形表示。エラー時は何番目の操作（op[2] のような位置）で、何が原因か（path が存在しない / 配列インデックスが範囲外 / test の値が一致しない / 不正な op）を明示。仕様の挙動を実機なしで再現したい backend 開発者、OpenAPI レビュー担当、Kubernetes の manifest patch を扱う担当者の手元検証に向く。

    🧐 よくある質問

    Q. JSON Patch（RFC 6902）と JSON Merge Patch（RFC 7396）の違いは? A. JSON Patch は「操作の配列」で、add / remove / replace / move / copy / test の 6 操作を順に適用する。Merge Patch は「変更後の差分そのもの」を送り、null でキー削除を表す簡易版で、move / copy / test を持たない。配列の精密な操作や、適用前提条件のチェックが要るなら JSON Patch を使う。

    Q. test 操作は何のためにある? A. 適用前に「ある path の値が期待どおりか」を確認するためのガード。先頭に test /version == 15 を置き、合致したときだけ後続の更新を適用すれば、同じ文書を別のリクエストが先に書き換えていた場合にパッチ全体を弾ける（楽観的ロックの一種）。

    Q. 1 つの操作が失敗したらどうなる? A. RFC 6902 はパッチを atomic（不可分）に扱う。途中の操作が失敗した時点でパッチ全体が失敗扱いになり、このツールは元のターゲット文書をそのまま返す。部分適用は起こらない。

    Q. path の /user/tags/- の - は何? A. 配列の末尾を指す特別な記号。add で - を使うと、その配列の最後に値を追加する。数値インデックスを指定すれば、その位置に挿入する。

    Q. path にスラッシュやチルダを含むキーはどう書く? A. JSON Pointer（RFC 6901）のエスケープを使う。キー名の中の / は ~1、~ は ~0 と書く。たとえば a/b というキーは /a~1b と表現する。

    📚 JSON Patch が REST の PATCH と相性が良い理由

    REST の PATCH は「リソースの部分更新」を表す動詞だが、HTTP 仕様自体は本文の形式を定めていない。そこで本文に JSON Patch を載せると、更新内容を「操作の列」として送れる。文書全体を送り直す PUT と違い、payload が小さく、test を併用すれば他者の変更を上書きしてしまう事故も防げる。さらに操作配列はそのまま監査ログとして読めるため、「いつ誰がどの path をどう変えたか」が人間にも追える。Kubernetes の kubectl patch --type=json もこの RFC 6902 形式を受け付ける。仕様を頭で追うより、実際に操作を並べて結果を見るほうが、move と copy の違いや test の効き方は早く腑に落ちる。