| < draft-ietf-appsawg-json-patch-06.txt | draft-ietf-appsawg-json-patch-07.txt > | |||
|---|---|---|---|---|
| Applications Area Working Group P. Bryan, Ed. | Applications Area Working Group P. Bryan, Ed. | |||
| Internet-Draft Salesforce.com | Internet-Draft Salesforce.com | |||
| Intended status: Informational M. Nottingham, Ed. | Intended status: Informational M. Nottingham, Ed. | |||
| Expires: April 25, 2013 October 22, 2012 | Expires: June 8, 2013 Akamai | |||
| December 5, 2012 | ||||
| JSON Patch | JSON Patch | |||
| draft-ietf-appsawg-json-patch-06 | draft-ietf-appsawg-json-patch-07 | |||
| Abstract | Abstract | |||
| JSON Patch defines the media type "application/json-patch", a JSON | JSON Patch defines the media type "application/json-patch", a JSON | |||
| document structure for expressing a sequence of operations to apply | document structure for expressing a sequence of operations to apply | |||
| to a JSON document. | to a JSON document. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 32 ¶ | skipping to change at page 1, line 33 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on April 25, 2013. | This Internet-Draft will expire on June 8, 2013. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 14 ¶ | skipping to change at page 2, line 14 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2. remove . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.3. replace . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.3. replace . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.4. move . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.4. move . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.5. copy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.5. copy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.6. test . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.6. test . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . 10 | Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| A.1. Adding an Object Member . . . . . . . . . . . . . . . . . 10 | A.1. Adding an Object Member . . . . . . . . . . . . . . . . . 10 | |||
| A.2. Adding an Array Element . . . . . . . . . . . . . . . . . 11 | A.2. Adding an Array Element . . . . . . . . . . . . . . . . . 11 | |||
| A.3. Removing an Object Member . . . . . . . . . . . . . . . . 11 | A.3. Removing an Object Member . . . . . . . . . . . . . . . . 11 | |||
| A.4. Removing an Array Element . . . . . . . . . . . . . . . . 11 | A.4. Removing an Array Element . . . . . . . . . . . . . . . . 12 | |||
| A.5. Replacing a Value . . . . . . . . . . . . . . . . . . . . 12 | A.5. Replacing a Value . . . . . . . . . . . . . . . . . . . . 12 | |||
| A.6. Moving a Value . . . . . . . . . . . . . . . . . . . . . . 12 | A.6. Moving a Value . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| A.7. Moving an Array Element . . . . . . . . . . . . . . . . . 13 | A.7. Moving an Array Element . . . . . . . . . . . . . . . . . 13 | |||
| A.8. Testing a Value: Success . . . . . . . . . . . . . . . . . 14 | A.8. Testing a Value: Success . . . . . . . . . . . . . . . . . 14 | |||
| A.9. Testing a Value: Error . . . . . . . . . . . . . . . . . . 14 | A.9. Testing a Value: Error . . . . . . . . . . . . . . . . . . 14 | |||
| A.10. Adding a nested Member Object . . . . . . . . . . . . . . 14 | A.10. Adding a nested Member Object . . . . . . . . . . . . . . 14 | |||
| A.11. Ignoring Unrecognized Elements . . . . . . . . . . . . . . 15 | A.11. Ignoring Unrecognized Elements . . . . . . . . . . . . . . 15 | |||
| A.12. Adding to a Non-existant Target . . . . . . . . . . . . . 15 | A.12. Adding to a Non-existant Target . . . . . . . . . . . . . 15 | |||
| A.13. Invalid JSON Patch Document . . . . . . . . . . . . . . . 16 | A.13. Invalid JSON Patch Document . . . . . . . . . . . . . . . 16 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| skipping to change at page 3, line 16 ¶ | skipping to change at page 3, line 16 ¶ | |||
| 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") for expressing a sequence of operations to apply to a | |||
| target JSON document, suitable for use with the HTTP PATCH method. | target JSON document, suitable for use with the HTTP PATCH method. | |||
| This format is also potentially useful in other cases when it's | ||||
| necessary to make partial updates to a JSON document. | ||||
| 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. | See Section 5 for information about handling errors. | |||
| 3. Document Structure | 3. Document Structure | |||
| A JSON Patch document is a JSON [RFC4627] document whose root is 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: | An example JSON Patch document: | |||
| [ | [ | |||
| { "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", "path": "/a/b/c", "to": "/a/b/d" }, | { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, | |||
| { "op": "copy", "path": "/a/b/d", "to": "/a/b/e" } | { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } | |||
| ] | ] | |||
| Evaluation of a JSON Patch document begins with a target JSON | Evaluation of a JSON Patch document begins with 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 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". The semantics of each | "remove", "replace", "move", "copy" or "test". The semantics of each | |||
| is defined below. | is defined below. | |||
| Additionally, operation objects MUST have exactly one "path" member, | Additionally, operation objects MUST have exactly one "path" member, | |||
| whose value MUST be a string containing a [JSON-Pointer] value that | whose value MUST be a string containing a [JSON-Pointer] value that | |||
| references the location within the target document to perform the | references a location within the target document to perform the | |||
| operation (the "target location"). | operation (the "target location"). | |||
| Other members of operation objects MUST be ignored, unless they are | Other members of operation objects MUST be ignored, unless they are | |||
| explicitly allowed by the definition of the operation. | explicitly allowed by the definition of the operation. | |||
| 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 operations 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 | ||||
| document; i.e., after unescaping takes place. | ||||
| 4.1. add | 4.1. add | |||
| The "add" operation adds a new value at the target location. The | The "add" operation adds a new value at the target location. The | |||
| operation object MUST contain a "value" member that specifies the | operation object MUST contain a "value" member that specifies the | |||
| value to be added. | value to be added. | |||
| When the operation is applied, the target location MUST reference one | ||||
| of: | ||||
| o the root of the target document, | ||||
| o a member to add to an existing object, or | ||||
| o an element to add to an existing array. | ||||
| For example: | For example: | |||
| { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] } | { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] } | |||
| If the target location references an element of an existing array, | When the operation is applied, the target location MUST reference one | |||
| any elements at or above the specified index are shifted one position | of: | |||
| to the right. The specified index MUST NOT be greater than the | ||||
| number of elements in the array. | ||||
| When the "-" character is used to index the end of the array, this | o The root of the target document - whereupon the specified value | |||
| has the effect of appending the value to the array. | becomes the entire content of the target document. | |||
| Note that this operation will, in common use, have a target location | o 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. | ||||
| o 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, this has the effect of appending the | ||||
| value to the array. | ||||
| Note that this operation can, in common use, have a target location | ||||
| that does not resolve to an existing value, resulting in the | that does not resolve to an existing value, resulting in the | |||
| pointer's error handling algorithm being invoked. This specification | pointer's error handling algorithm being invoked. This specification | |||
| defines the error handling algorithm for "add" pointers to explicitly | defines the error handling algorithm for "add" pointers to explicitly | |||
| ignore the error and perform the operation as specified. | ignore the error and perform the operation as specified. | |||
| However, if the object or array containing it does not exist, it is | ||||
| an error. | ||||
| For example, "add"ing to the path "/a/b" to this document: | ||||
| { "a": { "foo": 1 } } | ||||
| 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 } } | ||||
| because "a" does not exist. | ||||
| 4.2. remove | 4.2. remove | |||
| The "remove" operation removes the value at the target location. | The "remove" operation removes the value at the target location. | |||
| The target location MUST exist for the operation to be successful. | The target location MUST exist for the operation to be successful. | |||
| For example: | For example: | |||
| { "op": "remove", "path": "/a/b/c" } | { "op": "remove", "path": "/a/b/c" } | |||
| skipping to change at page 5, line 36 ¶ | skipping to change at page 6, line 9 ¶ | |||
| The "replace" operation replaces the value at the target location | The "replace" operation replaces the value at the target location | |||
| with a new value. The operation object MUST contain a "value" member | with a new value. The operation object MUST contain a "value" member | |||
| that specifies the replacement value. | that specifies the replacement value. | |||
| The target location MUST exist for the operation to be successful. | The target location MUST exist for the operation to be successful. | |||
| For example: | For example: | |||
| { "op": "replace", "path": "/a/b/c", "value": 42 } | { "op": "replace", "path": "/a/b/c", "value": 42 } | |||
| This operation is functionally identical to expressing a "remove" | This operation is functionally identical to a "remove" operation for | |||
| operation for a value, followed immediately by an "add" operation at | a value, followed immediately by an "add" operation at the same | |||
| 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 the target location and | The "move" operation removes the value at a specified location and | |||
| adds it to another location. | adds it to the target location. | |||
| The operation object MUST contain a "to" member, a string containing | ||||
| a JSON Pointer value that references the location in the target | ||||
| document to add the value to. | ||||
| The "to" location MUST reference one of: | The operation object MUST contain a "from" member, a string | |||
| containing a JSON Pointer value that references the location in the | ||||
| target document to move the value from. | ||||
| o the member to add to an existing object, or | The "from" location MUST exist for the operation to be successful. | |||
| o an element to add to an existing array. | ||||
| For example: | For example: | |||
| { "op": "move", "path": "/a/b/c", "to": "/a/b/d" } | { "op": "move", "from": "/a/b/c", "path": "/a/b/d" } | |||
| This operation is functionally identical to expressing a "remove" | ||||
| operation on the target location, followed immediately by an "add" | ||||
| operation at the "to" location with the value that was just removed. | ||||
| The location in the "to" member MUST NOT be part of the location | ||||
| defined by "path"; i.e., a location cannot be moved into one of its | ||||
| children. | ||||
| The location in the "to" member MUST NOT reference a member of an | This operation is functionally identical to a "remove" operation on | |||
| existing object in the target document, unless "path" and "to" | the "from" location, followed immediately by an "add" operation at | |||
| specify the same object, which has no effect. | the target location with the value that was just removed. | |||
| If the location in the "to" member references an element of an | The target location MUST NOT be part of the location defined by | |||
| existing array, any elements at or above the specified index are | "from"; i.e., a location cannot be moved into one of its children. | |||
| shifted one position to the right. The specified index MUST NOT be | ||||
| greater than the number of elements in the array. | ||||
| 4.5. copy | 4.5. copy | |||
| The "copy" operation copies the value at the target location to | The "copy" operation copies the value at a specified location to the | |||
| another location. | target location. | |||
| The operation object MUST contain a "to" member, a string containing | ||||
| a JSON Pointer value that references the location in the target | ||||
| document to add the value to. | ||||
| This location MUST reference one of: | ||||
| o the member to add to an existing object, or | The operation object MUST contain a "from" member, a string | |||
| containing a JSON Pointer value that references the location in the | ||||
| target document to copy the value from. | ||||
| o an element to add to an existing array. | The "from" location MUST exist for the operation to be successful. | |||
| For example: | For example: | |||
| { "op": "copy", "path": "/a/b/c", "to": "/a/b/e" } | { "op": "copy", "from": "/a/b/c", "path": "/a/b/e" } | |||
| The location in the "to" member MUST NOT be part of the location | ||||
| defined by "path"; i.e., a location cannot be copied into one of its | ||||
| children. | ||||
| The location in the "to" member MUST NOT reference a member of an | ||||
| existing object in the target document, unless "path" and "to" | ||||
| specify the same object, which has no effect. | ||||
| If the location in the "to" member references an element of an | This operation is functionally identical to an "add" operation at the | |||
| existing array, any elements at or above the specified index are | target location using the value specified in the "from". | |||
| shifted one position to the right. The specified index MUST NOT be | ||||
| greater than the number of elements in the array. | ||||
| 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 that at the target location. | |||
| 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 the | Here, "equal" means that the value at the target location and the | |||
| value conveyed by "value" are of the same JSON type, and considered | value conveyed by "value" are of the same JSON type, and considered | |||
| equal by the following rules for that type: | equal by the following rules for that type: | |||
| o strings: are considered equal if, after unescaping any sequence(s) | o strings: are considered equal if they contain the same number of | |||
| in both strings starting with a reverse solidus, they contain the | Unicode characters and their code points are position-wise equal. | |||
| same number of Unicode characters and their code points are | ||||
| position-wise equal. | ||||
| o numbers: are considered equal if subtracting one from the other | o numbers: are considered equal if their values are numerically | |||
| results in 0. | 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 each value can be considered equal to the value at the | |||
| corresponding position in the other array. | corresponding position in the other array. | |||
| 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 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 values | |||
| using this list of type-specific rules. | using this list of type-specific rules. | |||
| skipping to change at page 8, line 20 ¶ | skipping to change at page 8, line 11 ¶ | |||
| If a RFC2119 [RFC2119] requirement is violated by a JSON Patch | If a RFC2119 [RFC2119] requirement is violated by a JSON Patch | |||
| document, or if an operation is not successful, evaluation of the | document, or if an operation is not successful, evaluation of the | |||
| JSON Patch document SHOULD terminate and application of the entire | JSON Patch document SHOULD terminate and application of the entire | |||
| patch document SHALL NOT be deemed successful. | patch 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 as per [RFC5789], when used with the PATCH HTTP method, it | Note that the HTTP PATCH method is atomic, as per [RFC5789]. | |||
| is atomic. Therefore, the following patch would result in no changes | Therefore, the following patch would result in no changes being made | |||
| being made to the document at all (because the "test" operation | to the document at all (because the "test" operation results in an | |||
| 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. | |||
| skipping to change at page 9, line 37 ¶ | skipping to change at page 9, line 27 ¶ | |||
| 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]. | |||
| 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 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]. | ||||
| However, such browsers are not widely used ( estimated to comprise | ||||
| less than 1% of the market, at the time of writing). Publishers who | ||||
| are nevertheless concerned about this attack are 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, Paul Davis, Murray S. Kucherawy, Dean | Mike Acar, Mike Amundsen, Cyrus Daboo, Paul Davis, Murray S. | |||
| Landolt, Randall Leeds, James Manger, Julian Reschke, James Snell, | Kucherawy, Dean Landolt, Randall Leeds, James Manger, Julian | |||
| Eli Stevens. | 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 [RFC5261] specification. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [JSON-Pointer] | [JSON-Pointer] | |||
| Bryan, P. and K. Zyp, "JSON Pointer", | Bryan, P., Zyp, K., and M. Nottingham, "JSON Pointer", | |||
| draft-ietf-appsawg-json-pointer-04 (work in progress), | draft-ietf-appsawg-json-pointer-06 (work in progress), | |||
| March 2012. | 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. | |||
| 9.2. Informative References | 9.2. Informative References | |||
| [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses | ||||
| for Cross-Site Request Forgery". | ||||
| [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", | |||
| RFC 5789, March 2010. | RFC 5789, March 2010. | |||
| skipping to change at page 13, line 9 ¶ | skipping to change at page 13, line 9 ¶ | |||
| } | } | |||
| A.6. Moving a Value | A.6. Moving a Value | |||
| An example target JSON document: | An example target JSON document: | |||
| { | { | |||
| "foo": { | "foo": { | |||
| "bar": "baz", | "bar": "baz", | |||
| "waldo": "fred" | "waldo": "fred" | |||
| } | }, | |||
| "qux": { | "qux": { | |||
| "corge": "grault" | "corge": "grault" | |||
| } | } | |||
| } | } | |||
| A JSON Patch document: | A JSON Patch document: | |||
| [ | [ | |||
| { "op": "move", "path": "/foo/waldo", to: "/qux/thud" } | { "op": "move", "from": "/foo/waldo", "path": "/qux/thud" } | |||
| ] | ] | |||
| The resulting JSON document: | The resulting JSON document: | |||
| { | { | |||
| "foo": { | "foo": { | |||
| "bar": "baz" | "bar": "baz" | |||
| } | }, | |||
| "qux": { | "qux": { | |||
| "corge": "grault", | "corge": "grault", | |||
| "thud": "fred" | "thud": "fred" | |||
| } | } | |||
| } | } | |||
| A.7. Moving an Array Element | A.7. Moving an Array Element | |||
| An example target JSON document: | An example target JSON document: | |||
| { | { | |||
| "foo": [ "all", "grass", "cows", "eat" ] | "foo": [ "all", "grass", "cows", "eat" ] | |||
| } | } | |||
| A JSON Patch document: | A JSON Patch document: | |||
| [ | [ | |||
| { "op": "move", "path": "/foo/1", "to": "/foo/3" } | { "op": "move", "from": "/foo/1", "path": "/foo/3" } | |||
| ] | ] | |||
| The resulting JSON document: | The resulting JSON document: | |||
| { | { | |||
| "foo": [ "all", "cows", "eat", "grass" ] | "foo": [ "all", "cows", "eat", "grass" ] | |||
| } | } | |||
| A.8. Testing a Value: Success | A.8. Testing a Value: Success | |||
| skipping to change at page 15, line 24 ¶ | skipping to change at page 15, line 24 ¶ | |||
| 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", "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 Non-existant Target | |||
| skipping to change at page 16, line 10 ¶ | skipping to change at page 16, line 10 ¶ | |||
| would result in an error (therefore not being applied) because the | would result in an error (therefore not being applied) because the | |||
| "add" operation's target location that references neither the root of | "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 | the document, nor a member of an existing object, nor a member of an | |||
| existing array. | 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. A JSON parser that | since there is a later "op":"remove" element. A JSON parser that | |||
| hides such duplicate element names therefore cannot be used unless it | hides such duplicate element names therefore cannot be used unless it | |||
| always exposes only the last element with a given name (eg | always exposes only the last element with a given name (eg | |||
| "op":"remove" in this example). | "op":"remove" in this example). | |||
| 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 | ||||
| Email: mnot@mnot.net | Email: mnot@mnot.net | |||
| End of changes. 44 change blocks. | ||||
| 100 lines changed or deleted | 109 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||