[1] JSON Merge Patch は、 JSON の差分の表現方法の一つです。

仕様書

構文

[10] JSON に対する変更の指示を JSON によって記述します。

[11] 操作を明示するのではなく、構造と新しい値によって間接的に操作を記述しています。

[12] オブジェクトの値の追加・変更や削除は記述できますが、配列の編集は記述できず、配列を含むオブジェクトの編集として記述する必要があります。

[13] 最上位の値はオブジェクトでなければならず、それ以外の値は扱うことができません。また新しい値が null であるような追加・変更は記述できません。

MIME 型

[14] MIME型は application/merge-patch+json とされています >>2。

応用

[15] HTTP PATCH メソッドで使うことが想定されています >>2。

歴史

RFC 7386

  • [3] RFC 7386 - JSON Merge Patch ( 版) https://tools.ietf.org/html/rfc7386
  • [4] RFC Errata Report ( 版) http://www.rfc-editor.org/errata_search.php?rfc=7386
  • [5] appsawg in ietf 91 ( 版) http://www.ietf.org/proceedings/91/minutes/minutes-91-appsawg

[6] JSON Merge Patch は2014年10月に RFC 7386 として出版されました >>3 が、 RFC Editor の杜撰な空白の処理が原因で本文中の擬似コードの意味が不明瞭になっており >>4, >>5、同月中に改めて RFC 7396 >>2 として出版し直されています。

[7] JSON に関しては同年3月に RFC 7158 が RFC 7159 として再出版される珍事があったばかりでしたが (JSON の歴史の項を参照。)、1年も経たないうちにミスを繰り返す RFC Editor の失態には呆れる以前に呪われている気さえしてきます。

[8] さすがに今回は再出版でまた間違えるようなことはなかったようです。[9] 直前の Internet Draft まで正しかったものをわざわざ部外者である RFC Editor が再編集して誤りを混入させたり、一度出版するとどんなに深刻な不具合があっても修正できない RFC の歴史的な制約にいつまでもこだわり続けたりする IETF の標準化手続きには果たしてどれだけの意味があるのでしょうね?

関連

[16] JSON Patch とは名前が似ていますが異なります。 JSON Patch との互換性はありません。

[17] JSON Patch の方が JSON Merge Patch より記述できる変更の集合が大きいようです。

[18] Re: [Json] RFC 7386: correct indentation of the MergePatch function... ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg03402.html

[19] Buckets — Kinto 8.1.5 documentation () https://kinto.readthedocs.io/en/latest/api/1.x/buckets.html

JSON merge is currently supported using Content-Type: application/merge-patch+json.