RFC 6902 - JavaScript Object Notation (JSON) Patch （日本語訳）

1. 序論

JavaScript Object Notation （~JSON） `RFC4627$r は、構造~dataを［交換する／格納する］ための共通な形式である。 ~HTTP `PATCH$m `RFC5789$r は、資源に対し部分的な改変を遂行する~methodで，~HTTP（ Hypertext Transfer Protocol ） `RFC2616$r を拡張する。 ◎ JavaScript Object Notation (JSON) [RFC4627] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a method to perform partial modifications to resources.

~JSON~Patchは、~target~JSON文書に適用する一連の演算を表出するための（~MIME型 `application/json-patch+json^l により識別される）文書~形式である。これは~HTTP `PATCH$m ~methodでの利用に適するものである。 ◎ JSON Patch is a format (identified by the media type "application/json-patch+json") for expressing a sequence of operations to apply to a target JSON document; it is suitable for use with the HTTP PATCH method.

この形式は、~JSON文書, あるいは類似な拘束がある~data構造（すなわち，~JSON文法を利用して，~objや配列に直列化し得るもの）に対し部分的な更新が必要yであるような，他の事例にも有用になり得る。 ◎ This format is also potentially useful in other cases in which it is necessary to make partial updates to a JSON document or to a data structure that has similar constraints (i.e., they can be serialized as an object or an array using the JSON grammar).

2. 表記規約

この文書における句［ “〜しなければナラナイ（ `MUST^en ／ `SHALL^en ）”, “〜するベキである（ `SHOULD^en ）” ］は、 `RFC2119$r に述べるように解釈されるものとする。 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. 文書~構造

~JSON~Patch文書は、~objの配列を表現する~JSON文書 `RFC4627$r である。各~objは、~target~JSON文書に適用される 1 個の演算を表現する。 ◎ A JSON Patch document is a JSON [RFC4627] document that represents an array of objects. Each object represents a single operation to be applied to the target JSON document.

~HTTP `PATCH$m 要請により転送される~JSON~Patch文書の例を示す： ◎ The following is an example JSON Patch document, transferred in an HTTP PATCH request:

PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: "abc123"

[
  { "op": "test", "path": "/a/b/c", "value": "foo" },
  { "op": "remove", "path": "/a/b/c" },
  { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
  { "op": "replace", "path": "/a/b/c", "value": 42 },
  { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
  { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]

~JSON~Patch文書の評価は、最初は~target~JSON文書に対するものとして開始される。各~演算は、配列~内に現れる順に，逐次的に適用され、適用される度に，その結果の文書が次の演算の~target文書になる。評価は、すべての演算が成功裡に適用されるか, または~error条件に遭遇するまで継続される。 ◎ Evaluation of a JSON Patch document begins against a target JSON document. Operations are applied sequentially in the order they appear in the array. Each operation in the sequence is applied to the target document; the resulting document becomes the target of the next operation. Evaluation continues until all operations are successfully applied or until an error condition is encountered.

4. 演算

演算~objは、きっかり 1 個の `op^l ~memberを持たなければナラナイ。この~memberは，~target文書にて遂行される演算の種類を指示するものであり、その値は `add^l, `remove^l, `replace^l, `move^l, `copy^l, `test^l のいずれかでなければナラナイ — 他の値は~errorである。各種~objの意味論は後続の節にて定義される。 ◎ Operation objects MUST have exactly one "op" member, whose value indicates the operation to perform. Its value MUST be one of "add", "remove", "replace", "move", "copy", or "test"; other values are errors. The semantics of each object is defined below.

加えて、演算~objは，きっかり 1 個の `path^l ~memberを持たなければナラナイ。その~memberの値は、~target文書の中で演算が遂行される地点（ “~target地点” ）を指す，~JSON-Pointer値 `RFC6901$r を与える文字列である。 ◎ Additionally, operation objects MUST have exactly one "path" member. That member's value is a string containing a JSON-Pointer value [RFC6901] that references a location within the target document (the "target location") where the operation is performed.

演算~objの他の~memberの意味は，演算の~~種別ごとに定義される（後続の下位節にて述べる）。明示的に当の演算に関わるものと定義されていない~memberは、無視されなければナラナイ（すなわち，演算は、その演算に~~無関係な~memberについては ~objに元々現れなかったかのように，完了することになる）。 ◎ The meanings of other operation object members are defined by operation (see the subsections below). Members that are not explicitly defined for the operation in question MUST be ignored (i.e., the operation will complete as if the undefined member did not appear in the object).

~JSON~objの中での~memberの順序付けは、有意でないことに注意。したがって、次の演算~objは，いずれも等価である： ◎ Note that the ordering of members in JSON objects is not significant; therefore, the following operation objects are equivalent:

{ "op": "add", "path": "/a/b/c", "value": "foo" }
{ "path": "/a/b/c", "op": "add", "value": "foo" }
{ "value": "foo", "path": "/a/b/c", "op": "add" }

演算は、~JSON文書が表現する~data構造に（すなわち ~escape（ [RFC4627] § 2.5 ）が展開された後に），適用される。 ◎ Operations are applied to the data structures represented by a JSON document, i.e., after any unescaping (see [RFC4627], Section 2.5) takes place.

4.1. `add^c

`add^l 演算は、~target地点が指しているものに応じて，次のいずれかを遂行する： ◎ The "add" operation performs one of the following functions, depending upon what the target location references:

~target地点が配列~indexを指定している場合、その配列の中の指定された~indexの~~位置に，新たな値が挿入される。【 ~index 0 が先頭を指す： ~JSON-Pointerの評価 `RFC6901$r 】 ◎ If the target location specifies an array index, a new value is inserted into the array at the specified index.
~target地点が存在しない~obj~memberを指定している場合、その~objに新たな~memberが追加される。 ◎ If the target location specifies an object member that does not already exist, a new member is added to the object.
~target地点が存在する~obj~memberを指定している場合、その~memberの値が置換される。 ◎ If the target location specifies an object member that does exist, that member's value is replaced.

演算~objは、追加-用の値をとる， `value^l ~memberを持っていなければナラナイ。 ◎ The operation object MUST contain a "value" member whose content specifies the value to be added.

例： ◎ For example:

{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }

~target地点は、演算が適用される時点で，次のいずれかを参照していなければナラナイ： ◎ When the operation is applied, the target location MUST reference one of:

~target文書の~root — その結果，~target文書の内容~全体が，指定された値に置き換わる。 ◎ The root of the target document - whereupon the specified value becomes the entire content of the target document.

【指定された値が~objでも配列でもない場合の結果は，この仕様が参照する `RFC4627$r に従うなら合法でない~JSON文書になるが、それを廃用にした RFC 7159 に従えば合法になる。】
既存の~objに追加する~member — その結果、その~objの中の指示された地点に，指定された値が追加される。その~memberが既存のものであった場合、それは指定された値に置換される。 ◎ A member to add to an existing object - whereupon the supplied value is added to that object at the indicated location. If the member already exists, it is replaced by the specified value.
既存の配列に追加する要素 — その結果、その配列の中の指示された地点に，指定された値が追加される。指定された~index以上に~~位置する要素は， 1 つずつ後ろへずらされる。指定された~indexが配列の要素~数を超えてはナラナイ【~indexが要素~数に等しければ，末尾に付加する】。配列の末尾~indexを表す文字 `-^l が利用された場合（ `RFC6901$r を見よ）、値は配列の末尾に付加されることになる。 ◎ An element to add to an existing array - whereupon the supplied value is added to the array at the indicated location. Any elements at or above the specified index are shifted one position to the right. The specified index MUST NOT be greater than the number of elements in the array. If the "-" character is used to index the end of the array (see [RFC6901]), this has the effect of appending the value to the array.

この演算は，既存の~objや配列に値を追加するためにあるので、~target地点に値が存在しないことも度々あり得る。したがって，【 `RFC6901$r の定義により】 ~pointerの~errorを取扱う~algoが呼出されることになるが、この仕様は，［ `add^l の下での，~pointerの~errorを取扱う挙動は、その~errorを無視して，指定された値を追加する］ものと定義する。 ◎ Because this operation is designed to add to existing objects and arrays, its target location will often not exist. Although the pointer's error handling algorithm will thus be invoked, this specification defines the error handling behavior for "add" pointers to ignore that error and add the value as specified.

しかしながら、それを含む~obj自身または配列は，存在する必要があり、さもなければ~errorになる。 ◎ However, the object itself or an array containing it does need to exist, and it remains an error for that not to be the case.＼

例えば、次の文書から演算が開始されるときの，~target地点 `/a/b^s による `add^l は： ◎ For example, an "add" with a target location of "/a/b" starting with this document:

{ "a": { "foo": 1 } }

`a^s が存在するので~errorではなく，その値に `b^s に追加されることになる一方、次の文書の場合は： ◎ is not an error, because "a" exists, and "b" will be added to its value. It is an error in this document:

{ "q": { "bar": 2 } }

`a^s が存在しないので~errorになる。 ◎ because "a" does not exist.

4.2. `remove^c

`remove^l 演算は、~target地点から値を除去する。 ◎ The "remove" operation removes the value at the target location.

演算が成功するためには、~target地点が存在しなければナラナイ。 ◎ The target location MUST exist for the operation to be successful.

例： ◎ For example:

{ "op": "remove", "path": "/a/b/c" }

配列から要素が除去される際には、指定された~indexより先の要素は 1 つずつ先頭へずらされる。 ◎ If removing an element from an array, any elements above the specified index are shifted one position to the left.

4.3. `replace^c

`replace^l 演算は、~target地点の値を新たな値で置換する。演算~objは、置換用の値をとる `value^l ~memberを持っていなければナラナイ。 ◎ The "replace" operation replaces the value at the target location with a new value. The operation object MUST contain a "value" member whose content specifies the replacement value.

演算が成功するためには、~target地点が存在しなければナラナイ。 ◎ The target location MUST exist for the operation to be successful.

例： ◎ For example:

{ "op": "replace", "path": "/a/b/c", "value": 42 }

この演算は、 `remove^l 演算の直後に，同じ地点に，置換用の値を `add^l 演算により追加するのと、機能的に同じになる。 ◎ This operation is functionally identical to a "remove" operation for a value, followed immediately by an "add" operation at the same location with the replacement value.

4.4. `move^c

`move^l 演算は、指定された地点から値を除去して，~target地点にその値を追加する。 ◎ The "move" operation removes the value at a specified location and adds it to the target location.

演算~objは、~target文書~内の，値の移動-元~の地点を指す~JSON-Pointer文字列~値をとる， `from^l ~memberを含んでいなければナラナイ。 ◎ The operation object MUST contain a "from" member, which is a string containing a JSON Pointer value that references the location in the target document to move the value from.

演算が成功するためには、 "from" 地点が存在しなければナラナイ。 ◎ The "from" location MUST exist for the operation to be successful.

例： ◎ For example:

{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" }

この演算は、 "from" 地点に対する `remove^l 演算の直後に，その除去された値を， `add^l 演算により~target地点に追加するのと、機能的に同じになる。 ◎ This operation is functionally identical to a "remove" operation on the "from" location, followed immediately by an "add" operation at the target location with the value that was just removed.

【したがって、移動-先の~target地点は，除去した結果を基に適用されることになる（特に配列~要素を移動させる場合に注意：用例集 A.7 を見よ）。】

値をその子孫へ移動させることはできない。すなわち， `from^l が指す地点が `path^l が指す地点の適正な接頭辞になってはナラナイ。 ◎ The "from" location MUST NOT be a proper prefix of the "path" location; i.e., a location cannot be moved into one of its children.

【 “適正な接頭辞” （ `proper prefix^en ） — 上の例で述べるなら， `from^l が `path^l の先頭部分 `/a/b^s や `/a^s になってはならないが， `path^l と同じ `/a/b/d^s は許容される。（文字列として先頭一致する場合でも，例えば `from^l が `/a^s で `path^l が `/ab/c^s のような場合は、子孫ではないので “真の接頭辞” とはみなされない。）】

4.5. `copy^c

`copy^l 演算は、指定された地点から~target地点へ値を複製する。 ◎ The "copy" operation copies the value at a specified location to the target location.

演算~objには、~target文書の中の複製-元~の値の地点を指す~JSON-Pointer文字列~値をとる， `from^l ~memberが含まれていなければナラナイ。 ◎ The operation object MUST contain a "from" member, which is a string containing a JSON Pointer value that references the location in the target document to copy the value from.

演算が成功するためには、 "from" 地点が存在しなければナラナイ。 ◎ The "from" location MUST exist for the operation to be successful.

例： ◎ For example:

{ "op": "copy", "from": "/a/b/c", "path": "/a/b/e" }

この演算は、 `from^l ~memberにより指定される値を， `add^l 演算により~target地点に追加するのと、機能的に同じになる。 ◎ This operation is functionally identical to an "add" operation at the target location using the value specified in the "from" member.

4.6. `test^c

`test^l 演算は、~target地点の値が指定された値に `等しい^i かどうか~testする。 ◎ The "test" operation tests that a value at the target location is equal to a specified value.

演算~objには、~target地点の値と比較するための値をとる， `value^l ~memberが含まれていなければナラナイ。 ◎ The operation object MUST contain a "value" member that conveys the value to be compared to the target location's value.

演算が成功するためには、~target地点の値が `value^l の値と等しくなければナラナイ。 ◎ The target location MUST be equal to the "value" value for the operation to be considered successful.

ここで `等しい^i とは、~target地点の値と `value^l の値が同じ~JSON型であって, かつ［その型に応じて，以下に与える規則を満たす］ことを意味する： ◎ Here, "equal" means that the value at the target location and the value conveyed by "value" are of the same JSON type, and that they are considered equal by the following rules for that type:

文字列の場合: ［互いに同じ個数の~Unicode文字からなる］かつ［互いの符号位置~並びは~byteごとに等しい］。 ◎ strings: are considered equal if they contain the same number of Unicode characters and their code points are byte-by-byte equal.; 【 ~byteごとに（ `byte-by-byte^en ） — ~Unicodeの正準等価などの文字の等価性についての概念は適用せずに，単に符号単位に基づいて比較することを意味するものと見受けられる。】
数-の場合: 互いの値は数量的に等しい。 ◎ numbers: are considered equal if their values are numerically equal.
配列の場合: ［互いの要素~数は同じである］かつ［一方の配列~内にあるどの値も他方の配列~内の同じ~indexにある値と `等しい^i ］。 ◎ arrays: are considered equal if they contain the same number of values, and if each value can be considered equal to the value at the corresponding position in the other array, using this list of type-specific rules.
~objの場合: ［同じ個数の~memberからなる］かつ［それらの~memberの（文字列としての）~key名の集合は同じである］かつ［それらの~memberの同じ名前の~keyに対応する値は `等しい^i ］。 ◎ objects: are considered equal if they contain the same number of members, and if each member can be considered equal to a member in the other object, by comparing their keys (as strings) and their values (using this list of type-specific rules).; 【同じ名前の~keyが重複して存在する場合の扱いは、述べられていない。】
~literal（ `false^c, `true^c, `null^c ）の場合: 互いの値は同じである。 ◎ literals (false, true, and null): are considered equal if they are the same.

比較は論理的に【すなわち，~JSON~objとして解釈された後に】行われることに注意。例えば、配列を成す各~member値の合間にある空白は，比較においては有意でない。 ◎ Note that the comparison that is done is a logical comparison; e.g., whitespace between the member values of an array is not significant.

~obj~memberの直列化における順序付けも有意でないことに注意。 ◎ Also, note that ordering of the serialization of object members is not significant.

例： ◎ For example:

{ "op": "test", "path": "/a/b/c", "value": "foo" }

5. ~errorの取扱い

~JSON~Patch文書の規範的な要件に違反している場合, あるいは演算が成功裡に終わらなかった場合、~JSON~Patch文書の評価は終了されるベキであり，~patch文書全体の適用は成功と判断されてはナラナイ。 ◎ If a normative requirement is violated by a JSON Patch document, or if an operation is not successful, evaluation of the JSON Patch document SHOULD terminate and application of the entire patch document SHALL NOT be deemed successful.

【 “ベキ” — ~HTTP `PATCH$m ~methodの下での利用では，下記により “中途半端な成功” は明確に排除されているが、他の状況下では，選択の余地が残された記述になっている。】

`RFC5789$r § ~errorの取扱いにて、~JSON~Patchが~HTTP `PATCH$m ~methodに利用されたときに，~error条件に遭遇した際の取扱いが（種々の~error条件を指示するための，示唆される応答~codeなども含め）挙げられている。 ◎ See [RFC5789], Section 2.2 for considerations regarding handling errors when JSON Patch is used with the HTTP PATCH method, including suggested status codes to use to indicate various conditions.

`RFC5789$r に則り，~HTTP `PATCH$m ~methodは不可分になることに注意。したがって，次のような~patchでは、いかなる変更も文書に加えられないことになる（ `test^l 演算の結果が~errorになるので）： ◎ Note that the HTTP PATCH method is atomic, as per [RFC5789]. Therefore, the following patch would result in no changes being made to the document at all (because the "test" operation results in an error):

[
  { "op": "replace", "path": "/a/b/c", "value": 42 },
  { "op": "test", "path": "/a/b/c", "value": "C" }
]

6. IANA 考慮点

~JSON~Patch文書の~MIME型は `application/json-patch+json^c である。 ◎ The Internet media type for a JSON Patch document is application/ json-patch+json.

型~名 ◎ Type name

`application^c ◎ application

下位型~名 ◎ Subtype name

`json-patch+json^c ◎ json-patch+json

必須~parameter ◎ Required parameters

なし ◎ none

オプションの~parameter ◎ Optional parameters

なし ◎ none

符号化法についての考慮点 ◎ Encoding considerations

~binary ◎ binary

~securityの考慮点 ◎ Security considerations

§ 7，~securityの考慮点を見よ。 ◎ See Security Considerations in Section 7.

相互運用能の考慮点 ◎ Interoperability considerations

N/A

公表された仕様 ◎ Published specification

RFC 6902

この~MIME型の応用 ◎ Applications that use this media type

~JSON文書を操作する応用。 ◎ Applications that manipulate JSON documents.

追加的な情報 ◎ Additional information

Magic number(s): N/A
File extension(s): `.json-patch^c
Macintosh file type code(s): `TEXT^c

更なる情報についての連絡先 ◎ Person & email address to contact for further information

Paul C. Bryan <pbryan@anode.ca>

意図されている用途 ◎ Intended usage

COMMON

利用における制約 ◎ Restrictions on usage

なし ◎ none

著作者 ◎ Author

Paul C. Bryan <pbryan@anode.ca>

変更~制御者 ◎ Change controller

IETF

7. ~securityの考慮点

この仕様の~securityの考慮点は、 ~JSON `RFC4627$r と~JSON-Pointer `RFC6901$r と同じである。 ◎ This specification has the same security considerations as JSON [RFC4627] and JSON-Pointer [RFC6901].

少数の旧式~Web~browserにおいては、~accessが認証されている下でも，~rootが配列であるような任意の~JSON文書の読込ngにおいて，敏感な情報が含まれている~JSON~Patch文書が攻撃者に公開され得る。これは CSRF （ `Cross-Site Request Forgery^en, `CSRF$r ）として知られている。 ◎ A few older Web browsers can be coerced into loading an arbitrary JSON document whose root is an array, leading to a situation in which a JSON Patch document containing sensitive information could be exposed to attackers, even if access is authenticated. This is known as a Cross-Site Request Forgery (CSRF) attack [CSRF].

しかしながら、その種の~browserは広く利用されていない（この仕様が書かれた時点では、利用率は市場の 1% に満たないものと見積もられている）。にも拘らず，この攻撃が懸念されるならば、その種の文書が~HTTP `GET^m から可用になるのを避けるよう勧める。 ◎ However, such browsers are not widely used (at the time of writing, it is estimated that they are used in less than 1% of the market). Publishers who are nevertheless concerned about this attack are advised to avoid making such documents available with HTTP GET.

8. 謝辞

この仕様に案, ~feedback, 言い回しを寄せられた次の方々に： ◎ The following individuals contributed ideas, feedback and wording to this specification:

Mike Acar, Mike Amundsen, Cyrus Daboo, Paul Davis, Stefan Koegl, Murray S. Kucherawy, Dean Landolt, Randall Leeds, James Manger, Julian Reschke, James Snell, Eli Stevens, and Henry S. Thompson.

~JSON~Patch文書の構造は、 XMLPatch 文書~仕様 `RFC5261$r からの~~影響を受けている。 ◎ The structure of a JSON Patch document was influenced by the XML Patch document specification [RFC5261].

付録 A. 用例集

A.1. ~obj~memberの追加ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": "bar"}

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "add", "path": "/baz", "value": "qux" }
]

結果の~JSON文書： ◎ The resulting JSON document:

{
  `"baz": "qux",^mk
  "foo": "bar"
}

A.2. 配列~要素の追加ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": [ "bar", "baz" ] }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "add", "path": "/foo/`1^mk", "value": "qux" }
]

結果の~JSON文書： ◎ The resulting JSON document:

{ "foo": [ "bar", `"qux"^mk, "baz" ] }

A.3. ~obj~memberの除去ng

~target~JSON文書の例： ◎ An example target JSON document:

{
  `"baz": "qux"^mk,
  "foo": "bar"
}

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "remove", "path": "`/baz^mk" }
]

結果の~JSON文書： ◎ The resulting JSON document:

{ "foo": "bar" }

A.4. 配列~要素の除去ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": [ "bar", `"qux"^mk, "baz" ] }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "remove", "path": "/foo/`1^mk" }
]

結果の~JSON文書： ◎ The resulting JSON document:

{ "foo": [ "bar", "baz" ] }

A.5. 値の置換ng

~target~JSON文書の例： ◎ An example target JSON document:

{
  "baz": `"qux"^mk,
  "foo": "bar"
}

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "replace", "path": "/baz", "value": `"boo"^mk }
]

結果の~JSON文書： ◎ The resulting JSON document:

{
  "baz": `"boo"^mk,
  "foo": "bar"
}

A.6. 値の移動ng

~target~JSON文書の例： ◎ An example target JSON document:

{
  "foo": {
    "bar": "baz",
    `"waldo": "fred"^mk
  },
  "qux": {
    "corge": "grault"
  }
}

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "move", "from": "`/foo/waldo^mk", "path": "`/qux/thud^mk" }
]

結果の~JSON文書： ◎ The resulting JSON document:

{
  "foo": {
    "bar": "baz"
  },
  "qux": {
    "corge": "grault",
    `"thud": "fred"^mk
  }
}

A.7. 配列~要素の移動ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": [ "all", `"grass"^mk, "cows", "eat" ] }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "move", "from": "/foo/`1^mk", "path": "/foo/`3^mk" }
]

結果の~JSON文書： ◎ The resulting JSON document:

{ "foo": [ "all", "cows", "eat", `"grass"^mk ] }

A.8. 値の~test（成功）

~target~JSON文書の例： ◎ An example target JSON document:

{
  "baz": `"qux"^mk,
  "foo": [ "a", `2^mk, "c" ]
}

次の~JSON~Patch文書は成功裡に評価される： ◎ A JSON Patch document that will result in successful evaluation:

[
  { "op": "test", "path": "/baz", "value": `"qux"^mk },
  { "op": "test", "path": "/foo/1", "value": `2^mk }
]

A.9. 値の~test（~error）

~target~JSON文書の例： ◎ An example target JSON document:

{ "baz": `"qux"^mk }

次の~JSON~Patch文書は、 ~error条件になる： ◎ A JSON Patch document that will result in an error condition:

[
  { "op": "test", "path": "/baz", "value": `"bar"^mk }
]

A.10. 入子な~member~objの追加ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": "bar" }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "add", "path": "`/child^mk", "value": { "`grandchild^mk": { } } }
]

結果の~JSON文書： ◎ The resulting JSON document:

{
  "foo": "bar",
  "`child^mk": {
    "`grandchild^mk": {
    }
  }
}

A.11. 認識できない要素の無視ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": "bar" }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "add", "path": "/baz", "value": "qux", `"xyz": 123^mk }
]

結果の~JSON文書： ◎ The resulting JSON document:

{
  "foo": "bar",
  "baz": "qux"
}

A.12. 存在しない~target地点への追加ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": "bar" }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "add", "path": "`/baz/bat^mk", "value": "qux" }
]

この ~JSON~Patch文書が上の~target~JSON文書に適用されたときの結果は，~errorになる（したがって，適用されない）。 `add^l 演算の~target地点は［文書の~root, 既存の~objの~member, 既存の配列の~member ］のいずれも指していないので。 ◎ This JSON Patch document, applied to the target JSON document above, would result in an error (therefore, it would not be applied), because the "add" operation's target location that references neither the root of the document, nor a member of an existing object, nor a member of an existing array.

A.13. 無効な~JSON~Patch文書

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "`op^mk": "add", "path": "/baz", "value": "qux", "`op^mk": "remove" }
]

この~JSON~Patch文書は、 `add^l 演算として扱えない。後続に "op":"remove" があるので。 ~JSONの~obj~member名は一意である “ベキ” とされているおり、~member名の重複における~errorの取扱いは標準~化されていない。 ◎ This JSON Patch document cannot be treated as an "add" operation, because it contains a later "op":"remove" element. JSON requires that object member names be unique with a "SHOULD" requirement, and there is no standard error handling for duplicates.

A.14. `~^l による~escapeの取扱い

~target~JSON文書の例： ◎ An example target JSON document:

{
  "/": 9,
  "`~1^mk": 10
}

~JSON~Patch文書： ◎ A JSON Patch document:

[
  {"op": "test", "path": "`/~01^mk", "value": 10}
]

結果の~JSON文書： ◎ The resulting JSON document:

{
  "/": 9,
  "`~1^mk": 10
}

【 ~JSON-Pointer `/~01^s の “`~^c” による~escapeは `~0^s のみが展開され，それ以上は展開されない。 ~JSON-Pointerの評価 `RFC6901$r により， `~0^l は `~1^l より後に展開されるので。】

A.15. 文字列と数-の比較

~target~JSON文書の例： ◎ An example target JSON document:

{
  "/": 9,
  "~1": `10^mk
}

~JSON~Patch文書： ◎ A JSON Patch document:

[
  {"op": "test", "path": "/~01", "value": `"10"^mk}
]

この結果は~testが失敗するので~errorになる。文書の方の値は数-である一方，~testされる値は文字列なので。 ◎ This results in an error, because the test fails. The document value is numeric, whereas the value being tested for is a string.

A.16. 配列~値の追加ng

~target~JSON文書の例： ◎ An example target JSON document:

{ "foo": ["bar"] }

~JSON~Patch文書： ◎ A JSON Patch document:

[
  { "op": "add", "path": "/foo/`-^mk", "value": ["abc", "def"] }
]

結果の~JSON文書： ◎ The resulting JSON document:

{ "foo": ["bar"`, ["abc", "def"]^mk] }

JSON Patch

このメモの位置付け

著作権の告知

1. 序論

2. 表記規約

3. 文書~構造

4. 演算

4.1. `add^c

4.2. `remove^c

4.3. `replace^c

4.4. `move^c

4.5. `copy^c

4.6. `test^c

5. ~errorの取扱い

6. IANA 考慮点

7. ~securityの考慮点

8. 謝辞

付録 A. 用例集

A.1. ~obj~memberの追加ng

A.2. 配列~要素の追加ng

A.3. ~obj~memberの除去ng

A.4. 配列~要素の除去ng

A.5. 値の置換ng

A.6. 値の移動ng

A.7. 配列~要素の移動ng

A.8. 値の~test（成功）

A.9. 値の~test（~error）

A.10. 入子な~member~objの追加ng

A.11. 認識できない要素の無視ng

A.12. 存在しない~target地点への追加ng

A.13. 無効な~JSON~Patch文書

A.14. `~^l による~escapeの取扱い

A.15. 文字列と数-の比較

A.16. 配列~値の追加ng