draft-ietf-appsawg-json-patch-10.txt   rfc6902.txt 
Applications Area Working Group P. Bryan, Ed. Internet Engineering Task Force (IETF) P. Bryan, Ed.
Internet-Draft Salesforce.com Request for Comments: 6902 Salesforce.com
Intended status: Standards Track M. Nottingham, Ed. Category: Standards Track M. Nottingham, Ed.
Expires: July 24, 2013 Akamai ISSN: 2070-1721 Akamai
January 20, 2013 April 2013
JSON Patch JavaScript Object Notation (JSON) Patch
draft-ietf-appsawg-json-patch-10
Abstract Abstract
JSON Patch defines a JSON document structure for expressing a JSON Patch defines a JSON document structure for expressing a
sequence of operations to apply to a JavaScript Object Notation sequence of operations to apply to a JavaScript Object Notation
(JSON) document, suitable for use with the HTTP PATCH method. The (JSON) document; it is suitable for use with the HTTP PATCH method.
"application/json-patch" media type is used to identify such patch The "application/json-patch+json" media type is used to identify such
documents. patch documents.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 24, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6902.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 18
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Document Structure . . . . . . . . . . . . . . . . . . . . . . 3 3. Document Structure . . . . . . . . . . . . . . . . . . . . . . 3
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. add . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. add . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. remove . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. remove . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. replace . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. replace . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. move . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. move . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. copy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. copy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. test . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6. test . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Adding an Object Member . . . . . . . . . . . . . . . . . 11 A.1. Adding an Object Member . . . . . . . . . . . . . . . . . 12
A.2. Adding an Array Element . . . . . . . . . . . . . . . . . 11 A.2. Adding an Array Element . . . . . . . . . . . . . . . . . 12
A.3. Removing an Object Member . . . . . . . . . . . . . . . . 12 A.3. Removing an Object Member . . . . . . . . . . . . . . . . 12
A.4. Removing an Array Element . . . . . . . . . . . . . . . . 12 A.4. Removing an Array Element . . . . . . . . . . . . . . . . 13
A.5. Replacing a Value . . . . . . . . . . . . . . . . . . . . 12 A.5. Replacing a Value . . . . . . . . . . . . . . . . . . . . 13
A.6. Moving a Value . . . . . . . . . . . . . . . . . . . . . . 13 A.6. Moving a Value . . . . . . . . . . . . . . . . . . . . . . 14
A.7. Moving an Array Element . . . . . . . . . . . . . . . . . 13 A.7. Moving an Array Element . . . . . . . . . . . . . . . . . 14
A.8. Testing a Value: Success . . . . . . . . . . . . . . . . . 14 A.8. Testing a Value: Success . . . . . . . . . . . . . . . . . 15
A.9. Testing a Value: Error . . . . . . . . . . . . . . . . . . 14 A.9. Testing a Value: Error . . . . . . . . . . . . . . . . . . 15
A.10. Adding a nested Member Object . . . . . . . . . . . . . . 14 A.10. Adding a Nested Member Object . . . . . . . . . . . . . . 15
A.11. Ignoring Unrecognized Elements . . . . . . . . . . . . . . 15 A.11. Ignoring Unrecognized Elements . . . . . . . . . . . . . . 16
A.12. Adding to a Non-existant Target . . . . . . . . . . . . . 15 A.12. Adding to a Nonexistent Target . . . . . . . . . . . . . . 16
A.13. Invalid JSON Patch Document . . . . . . . . . . . . . . . 16 A.13. Invalid JSON Patch Document . . . . . . . . . . . . . . . 17
A.14. ~ Escape Ordering . . . . . . . . . . . . . . . . . . . . 16 A.14. ~ Escape Ordering . . . . . . . . . . . . . . . . . . . . 17
A.15. Comparing Strings and Numbers . . . . . . . . . . . . . . 16 A.15. Comparing Strings and Numbers . . . . . . . . . . . . . . 17
A.16. Adding an Array Value . . . . . . . . . . . . . . . . . . 17 A.16. Adding an Array Value . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
JavaScript Object Notation (JSON) [RFC4627] is a common format for JavaScript Object Notation (JSON) [RFC4627] is a common format for
the exchange and storage of structured data. HTTP PATCH [RFC5789] the exchange and storage of structured data. HTTP PATCH [RFC5789]
extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a
method to perform partial modifications to resources. method to perform partial modifications to resources.
JSON Patch is a format (identified by the media type "application/ JSON Patch is a format (identified by the media type "application/
json-patch") for expressing a sequence of operations to apply to a json-patch+json") for expressing a sequence of operations to apply to
target JSON document, suitable for use with the HTTP PATCH method. a target JSON document; it is suitable for use with the HTTP PATCH
method.
This format is also potentially useful in other cases where necessary This format is also potentially useful in other cases in which it is
to make partial updates to a JSON document, or to a data structure necessary to make partial updates to a JSON document or to a data
that has similar constraints (i.e., they can be serialised as an structure that has similar constraints (i.e., they can be serialized
object or an array using the JSON grammar). as an object or an array using the JSON grammar).
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
See Section 5 for information about handling errors.
3. Document Structure 3. Document Structure
A JSON Patch document is a JSON [RFC4627] document that represents an A JSON Patch document is a JSON [RFC4627] document that represents an
array of objects. Each object represents a single operation to be array of objects. Each object represents a single operation to be
applied to the target JSON document. applied to the target JSON document.
An example JSON Patch document, transferred in a HTTP PATCH request: The following is an example JSON Patch document, transferred in an
HTTP PATCH request:
PATCH /my/data HTTP/1.1 PATCH /my/data HTTP/1.1
Host: example.org Host: example.org
Content-Length: 326 Content-Length: 326
Content-Type: application/json-patch Content-Type: application/json-patch+json
If-Match: "abc123" If-Match: "abc123"
[ [
{ "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" }, { "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
] ]
Evaluation of a JSON Patch document begins against a target JSON Evaluation of a JSON Patch document begins against a target JSON
document. Operations are applied sequentially in the order they document. Operations are applied sequentially in the order they
appear in the array. Each operation in the sequence is applied to appear in the array. Each operation in the sequence is applied to
the target document; the resulting document becomes the target of the the target document; the resulting document becomes the target of the
next operation. Evaluation continues until all operations are next operation. Evaluation continues until all operations are
successfully applied, or an error condition is encountered. successfully applied or until an error condition is encountered.
4. Operations 4. Operations
Operation objects MUST have exactly one "op" member, whose value Operation objects MUST have exactly one "op" member, whose value
indicates the operation to perform. Its value MUST be one of "add", indicates the operation to perform. Its value MUST be one of "add",
"remove", "replace", "move", "copy" or "test"; other values are "remove", "replace", "move", "copy", or "test"; other values are
errors. The semantics of each is defined below. errors. The semantics of each object is defined below.
Additionally, operation objects MUST have exactly one "path" member. Additionally, operation objects MUST have exactly one "path" member.
That member's value is a string containing a [JSON-Pointer] value That member's value is a string containing a JSON-Pointer value
that references a location within the target document (the "target [RFC6901] that references a location within the target document (the
location") where the operation is performed. "target location") where the operation is performed.
The meanings of other members of operation objects are defined by The meanings of other operation object members are defined by
operation (see the subsections below). Members that are not operation (see the subsections below). Members that are not
explicitly defined for the operation in question MUST be ignored explicitly defined for the operation in question MUST be ignored
(i.e., the operation will complete as if the undefined member did not (i.e., the operation will complete as if the undefined member did not
appear in the object). appear in the object).
Note that the ordering of members in JSON objects is not significant; Note that the ordering of members in JSON objects is not significant;
therefore, the following operation objects are equivalent: therefore, the following operation objects are equivalent:
{ "op": "add", "path": "/a/b/c", "value": "foo" } { "op": "add", "path": "/a/b/c", "value": "foo" }
{ "path": "/a/b/c", "op": "add", "value": "foo" } { "path": "/a/b/c", "op": "add", "value": "foo" }
{ "value": "foo", "path": "/a/b/c", "op": "add" } { "value": "foo", "path": "/a/b/c", "op": "add" }
Operations are applied to the data structures represented by a JSON Operations are applied to the data structures represented by a JSON
document; i.e., after any unescaping (see [RFC4627], Section 2.5) document, i.e., after any unescaping (see [RFC4627], Section 2.5)
takes place. takes place.
4.1. add 4.1. add
The "add" operation performs the following function, depending upon The "add" operation performs one of the following functions,
what the target location references: depending upon what the target location references:
o If the target location specifies an array index, a new value is o If the target location specifies an array index, a new value is
inserted into the array at the specified index. inserted into the array at the specified index.
o If the target location specifies an object member that does not o If the target location specifies an object member that does not
already exist, a new member is added to the object. already exist, a new member is added to the object.
o If the target location specifies an object member that does exist, o If the target location specifies an object member that does exist,
that member's value is replaced. that member's value is replaced.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
o A member to add to an existing object - whereupon the supplied o A member to add to an existing object - whereupon the supplied
value is added to that object at the indicated location. If the value is added to that object at the indicated location. If the
member already exists, it is replaced by the specified value. member already exists, it is replaced by the specified value.
o An element to add to an existing array - whereupon the supplied o An element to add to an existing array - whereupon the supplied
value is added to the array at the indicated location. Any value is added to the array at the indicated location. Any
elements at or above the specified index are shifted one position elements at or above the specified index are shifted one position
to the right. The specified index MUST NOT be greater than the to the right. The specified index MUST NOT be greater than the
number of elements in the array. If the "-" character is used to number of elements in the array. If the "-" character is used to
index the end of the array (see [JSON-Pointer]), this has the index the end of the array (see [RFC6901]), this has the effect of
effect of appending the value to the array. appending the value to the array.
Because this operation is designed to add to existing objects and Because this operation is designed to add to existing objects and
arrays, its target location will often not exist. Although the arrays, its target location will often not exist. Although the
pointer's error handling algorithm will thus be invoked, this pointer's error handling algorithm will thus be invoked, this
specification defines the error handling behaviour for "add" pointers specification defines the error handling behavior for "add" pointers
to ignore that error and add the value as specified. to ignore that error and add the value as specified.
However, the object itself or an array containing it does need to 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. For exist, and it remains an error for that not to be the case. For
example, an "add" with a target location of "/a/b" starting with this example, an "add" with a target location of "/a/b" starting with this
document: document:
{ "a": { "foo": 1 } } { "a": { "foo": 1 } }
is not an error, because "a" exists, and "b" will be added to its is not an error, because "a" exists, and "b" will be added to its
skipping to change at page 6, line 39 skipping to change at page 6, line 39
This operation is functionally identical to a "remove" operation for This operation is functionally identical to a "remove" operation for
a value, followed immediately by an "add" operation at the same a value, followed immediately by an "add" operation at the same
location with the replacement value. location with the replacement value.
4.4. move 4.4. move
The "move" operation removes the value at a specified location and The "move" operation removes the value at a specified location and
adds it to the target location. adds it to the target location.
The operation object MUST contain a "from" member, a string The operation object MUST contain a "from" member, which is a string
containing a JSON Pointer value that references the location in the containing a JSON Pointer value that references the location in the
target document to move the value from. target document to move the value from.
The "from" location MUST exist for the operation to be successful. The "from" location MUST exist for the operation to be successful.
For example: For example:
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" } { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }
This operation is functionally identical to a "remove" operation on This operation is functionally identical to a "remove" operation on
skipping to change at page 7, line 13 skipping to change at page 7, line 13
the target location with the value that was just removed. the target location with the value that was just removed.
The "from" location MUST NOT be a proper prefix of the "path" 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. location; i.e., a location cannot be moved into one of its children.
4.5. copy 4.5. copy
The "copy" operation copies the value at a specified location to the The "copy" operation copies the value at a specified location to the
target location. target location.
The operation object MUST contain a "from" member, a string The operation object MUST contain a "from" member, which is a string
containing a JSON Pointer value that references the location in the containing a JSON Pointer value that references the location in the
target document to copy the value from. target document to copy the value from.
The "from" location MUST exist for the operation to be successful. The "from" location MUST exist for the operation to be successful.
For example: For example:
{ "op": "copy", "from": "/a/b/c", "path": "/a/b/e" } { "op": "copy", "from": "/a/b/c", "path": "/a/b/e" }
This operation is functionally identical to an "add" operation at the This operation is functionally identical to an "add" operation at the
target location using the value specified in the "from" member. target location using the value specified in the "from" member.
4.6. test 4.6. test
The "test" operation tests that a value at the target location is The "test" operation tests that a value at the target location is
equal to a specified value. equal to a specified value.
The operation object MUST contain a "value" member that conveys the The operation object MUST contain a "value" member that conveys the
value to be compared to that at the target location. value to be compared to the target location's value.
The target location MUST be equal to the "value" value for the The target location MUST be equal to the "value" value for the
operation to be considered successful. operation to be considered successful.
Here, "equal" means that the value at the target location and that Here, "equal" means that the value at the target location and the
conveyed by "value" are of the same JSON type, and considered equal value conveyed by "value" are of the same JSON type, and that they
by the following rules for that type: are considered equal by the following rules for that type:
o strings: are considered equal if they contain the same number of o strings: are considered equal if they contain the same number of
Unicode characters and their code points are position-wise equal. Unicode characters and their code points are byte-by-byte equal.
o numbers: are considered equal if their values are numerically o numbers: are considered equal if their values are numerically
equal. equal.
o arrays: are considered equal if they contain the same number of o arrays: are considered equal if they contain the same number of
values, and each value can be considered equal to the value at the values, and if each value can be considered equal to the value at
corresponding position in the other array, using this list of the corresponding position in the other array, using this list of
type-specific rules. type-specific rules.
o objects: are considered equal if they contain the same number of o objects: are considered equal if they contain the same number of
members, and each member can be considered equal to a member in members, and if each member can be considered equal to a member in
the other object, by comparing their keys as strings, and values the other object, by comparing their keys (as strings) and their
using this list of type-specific rules. values (using this list of type-specific rules).
o literals (false, true and null): are considered equal if they are o literals (false, true, and null): are considered equal if they are
the same. the same.
Note that this is a logical comparison; e.g., whitespace between the Note that the comparison that is done is a logical comparison; e.g.,
member values of an array is not significant. whitespace between the member values of an array is not significant.
Also, note that ordering of the serialisation of object members is Also, note that ordering of the serialization of object members is
not significant. not significant.
For example: For example:
{ "op": "test", "path": "/a/b/c", "value": "foo" } { "op": "test", "path": "/a/b/c", "value": "foo" }
5. Error Handling 5. Error Handling
If a normative requirement is violated by a JSON Patch document, or If a normative requirement is violated by a JSON Patch document, or
if an operation is not successful, evaluation of the JSON Patch if an operation is not successful, evaluation of the JSON Patch
document SHOULD terminate and application of the entire patch document SHOULD terminate and application of the entire patch
document SHALL NOT be deemed successful. document SHALL NOT be deemed successful.
See [RFC5789], Section 2.2 for considerations regarding handling See [RFC5789], Section 2.2 for considerations regarding handling
errors when JSON Patch is used with the HTTP PATCH method, including errors when JSON Patch is used with the HTTP PATCH method, including
suggested status codes to use to indicate various conditions. suggested status codes to use to indicate various conditions.
Note that the HTTP PATCH method is atomic, as per [RFC5789]. Note that the HTTP PATCH method is atomic, as per [RFC5789].
Therefore, the following patch would result in no changes being made Therefore, the following patch would result in no changes being made
to the document at all (because the "test" operation results in an to the document at all (because the "test" operation results in an
error). error):
[ [
{ "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "test", "path": "/a/b/c", "value": "C" } { "op": "test", "path": "/a/b/c", "value": "C" }
] ]
6. IANA Considerations 6. IANA Considerations
The Internet media type for a JSON Patch document is application/ The Internet media type for a JSON Patch document is application/
json-patch. json-patch+json.
Type name: application Type name: application
Subtype name: json-patch Subtype name: json-patch+json
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: binary Encoding considerations: binary
Security considerations: Security considerations:
See Security Considerations in section 7. See Security Considerations in Section 7.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: Published specification:
[this memo] RFC 6902
Applications that use this media type: Applications that use this media type:
Applications that manipulate JSON documents. Applications that manipulate JSON documents.
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
File extension(s): .json-patch File extension(s): .json-patch
skipping to change at page 9, line 48 skipping to change at page 10, line 8
Restrictions on usage: none Restrictions on usage: none
Author: Paul C. Bryan <pbryan@anode.ca> Author: Paul C. Bryan <pbryan@anode.ca>
Change controller: IETF Change controller: IETF
7. Security Considerations 7. Security Considerations
This specification has the same security considerations as JSON This specification has the same security considerations as JSON
[RFC4627] and [JSON-Pointer]. [RFC4627] and JSON-Pointer [RFC6901].
A few older Web browsers can be coerced into loading an arbitrary A few older Web browsers can be coerced into loading an arbitrary
JSON document whose root is an array, leading to a situation where a JSON document whose root is an array, leading to a situation in which
JSON Patch document containing sensitive information could be exposed a JSON Patch document containing sensitive information could be
to attackers, even if access is authenticated. This is known as a exposed to attackers, even if access is authenticated. This is known
Cross-Site Request Forgery (CSRF) attack [CSRF]. as a Cross-Site Request Forgery (CSRF) attack [CSRF].
However, such browsers are not widely used ( estimated to comprise However, such browsers are not widely used (at the time of writing,
less than 1% of the market, at the time of writing). Publishers who it is estimated that they are used in less than 1% of the market).
are nevertheless concerned about this attack are advised to avoid Publishers who are nevertheless concerned about this attack are
making such documents available with HTTP GET. advised to avoid making such documents available with HTTP GET.
8. Acknowledgements 8. Acknowledgements
The following individuals contributed ideas, feedback and wording to The following individuals contributed ideas, feedback and wording to
this specification: this specification:
Mike Acar, Mike Amundsen, Cyrus Daboo, Paul Davis, Stefan Koegl, Mike Acar, Mike Amundsen, Cyrus Daboo, Paul Davis, Stefan Koegl,
Murray S. Kucherawy, Dean Landolt, Randall Leeds, James Manger, Murray S. Kucherawy, Dean Landolt, Randall Leeds, James Manger,
Julian Reschke, James Snell, Eli Stevens and Henry S. Thompson. Julian Reschke, James Snell, Eli Stevens, and Henry S. Thompson.
The structure of a JSON Patch document was influenced by the XML The structure of a JSON Patch document was influenced by the XML
Patch document [RFC5261] specification. Patch document specification [RFC5261].
9. References 9. References
9.1. Normative References 9.1. Normative References
[JSON-Pointer]
Bryan, P., Zyp, K., and M. Nottingham, "JSON Pointer",
draft-ietf-appsawg-json-pointer-07 (work in progress),
November 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
April 2013.
9.2. Informative References 9.2. Informative References
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery". for Cross-Site Request Forgery", ACM Conference
on Computer and Communications Security, October 2008,
<http://seclab.stanford.edu/websec/csrf/csrf.pdf>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath) Operations Framework Utilizing XML Path Language (XPath)
Selectors", RFC 5261, September 2008. Selectors", RFC 5261, September 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
skipping to change at page 14, line 41 skipping to change at page 15, line 33
An example target JSON document: An example target JSON document:
{ "baz": "qux" } { "baz": "qux" }
A JSON Patch document that will result in an error condition: A JSON Patch document that will result in an error condition:
[ [
{ "op": "test", "path": "/baz", "value": "bar" } { "op": "test", "path": "/baz", "value": "bar" }
] ]
A.10. Adding a nested Member Object A.10. Adding a Nested Member Object
An example target JSON document: An example target JSON document:
{ "foo": "bar" } { "foo": "bar" }
A JSON Patch document: A JSON Patch document:
[ [
{ "op": "add", "path": "/child", "value": { "grandchild": { } } } { "op": "add", "path": "/child", "value": { "grandchild": { } } }
] ]
skipping to change at page 15, line 33 skipping to change at page 16, line 33
{ "op": "add", "path": "/baz", "value": "qux", "xyz": 123 } { "op": "add", "path": "/baz", "value": "qux", "xyz": 123 }
] ]
The resulting JSON document: The resulting JSON document:
{ {
"foo": "bar", "foo": "bar",
"baz": "qux" "baz": "qux"
} }
A.12. Adding to a Non-existant Target A.12. Adding to a Nonexistent Target
An example target JSON document: An example target JSON document:
{ "foo": "bar" } { "foo": "bar" }
A JSON Patch document: A JSON Patch document:
[ [
{ "op": "add", "path": "/baz/bat", "value": "qux" } { "op": "add", "path": "/baz/bat", "value": "qux" }
] ]
This JSON Patch document, applied to the target JSON document above, This JSON Patch document, applied to the target JSON document above,
would result in an error (therefore not being applied) because the would result in an error (therefore, it would not be applied),
"add" operation's target location that references neither the root of because the "add" operation's target location that references neither
the document, nor a member of an existing object, nor a member of an the root of the document, nor a member of an existing object, nor a
existing array. member of an existing array.
A.13. Invalid JSON Patch Document A.13. Invalid JSON Patch Document
A JSON Patch document: A JSON Patch document:
[ [
{ "op": "add", "path": "/baz", "value": "qux", "op": "remove" } { "op": "add", "path": "/baz", "value": "qux", "op": "remove" }
] ]
This JSON Patch document cannot be treated as an "add" operation This JSON Patch document cannot be treated as an "add" operation,
since there is a later "op":"remove" element. JSON requires that because it contains a later "op":"remove" element. JSON requires
object member names be unique with a "SHOULD" requirement, and there that object member names be unique with a "SHOULD" requirement, and
is no standard error handling for duplicates. there is no standard error handling for duplicates.
A.14. ~ Escape Ordering A.14. ~ Escape Ordering
An example target JSON document: An example target JSON document:
{ {
"/": 9, "/": 9,
"~1": 10 "~1": 10
} }
skipping to change at page 16, line 48 skipping to change at page 18, line 4
} }
A.15. Comparing Strings and Numbers A.15. Comparing Strings and Numbers
An example target JSON document: An example target JSON document:
{ {
"/": 9, "/": 9,
"~1": 10 "~1": 10
} }
A JSON Patch document: A JSON Patch document:
[ [
{"op": "test", "path": "/~01", "value": "10"} {"op": "test", "path": "/~01", "value": "10"}
] ]
This results in an error, because the test fails; the document value This results in an error, because the test fails. The document value
is numeric, whereas the value tested for is a string. is numeric, whereas the value being tested for is a string.
A.16. Adding an Array Value A.16. Adding an Array Value
An example target JSON document: An example target JSON document:
{ "foo": ["bar"] } { "foo": ["bar"] }
A JSON Patch document: A JSON Patch document:
[ [
skipping to change at page 17, line 32 skipping to change at page 18, line 35
The resulting JSON document: The resulting JSON document:
{ "foo": ["bar", ["abc", "def"]] } { "foo": ["bar", ["abc", "def"]] }
Authors' Addresses Authors' Addresses
Paul C. Bryan (editor) Paul C. Bryan (editor)
Salesforce.com Salesforce.com
Phone: +1 604 783 1481 Phone: +1 604 783 1481
Email: pbryan@anode.ca EMail: pbryan@anode.ca
Mark Nottingham (editor) Mark Nottingham (editor)
Akamai Akamai
Email: mnot@mnot.net EMail: mnot@mnot.net
 End of changes. 55 change blocks. 
118 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/