You are reading it correctly. Note also that the very next bullet point says:
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. So an "add" is really a "replace" that does not have the "target location MUST exist" restriction. Personally, I'm not too fond of that decision. For anything other than an array, "add" should fail if the target already exists. For arrays, "add" should insert but never replace an existing value. - James On Tue, Dec 11, 2012 at 7:25 AM, Barry Leiba <[email protected]>wrote: > > Abstract > > JSON Patch defines the media type "application/json-patch", a JSON > > document structure for expressing a sequence of operations to apply > > to a JSON document, suitable for use with the HTTP PATCH method. > ... > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/ > > I've reviewed JSON Patch and JSON Pointer as responsible AD, and am > very happy with the documents -- this is good work, well written. I > came up with one issue that I want to discuss as part of last call: > > 4.1. add > > The "add" operation adds a new value at the target location. The > operation object MUST contain a "value" member that specifies the > value to be added. > > For example: > > { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] } > > When the operation is applied, the target location MUST reference one > of: > > o The root of the target document - whereupon the specified value > becomes the entire content of the target document. > > Now, what this means is that if we start with this: > > { "a": { "num": 1 } } > > and we apply this: > > { "op": "add", "path": "", "value": [ "foo", "bar" ] } > > we end up with this: > > [ "foo", "bar" ] > > This doesn't strike me as having any sense of an "add" operation -- it > appears to be a special case that doesn't fit. In any other > situation, using any other path, the operation either adds something > to what's already there, or it fails. But when the path is "", it's > anomalous. > > So, three questions: > > 1. Do I have this right, or am I mistaken about the result of that > operation? > > 2. Assuming I have it right, can someone explain why it's this way? > > 3. Can someone explain why this is the right way to specify it, rather > than using "replace" for this? > > Barry > _______________________________________________ > apps-discuss mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/apps-discuss >
