ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-appsawg-json-patch-08.txt> (JSON Patch) to Proposed Standard

2012-12-11 18:24:56
"add" has the semantics of "make the value *this*".

Yeh, I guess the problem I have with that is that that's not the
semantics most of us attach to the concept of "add a thing to a set".
And it bothers me that "add to an object" and "add to an array" have
different semantics.

That difference is unsettling.  It's OK to have "add" on an array have
the semantics of "insert", especially because there's no "insert"
action.  But having "add" on an object have the semantics of "replace"
seems bad, partly because it's inconsistent with the semantics it has
on an array and because there's already a "replace" action.

If I have { "baz": "qux", "foo": "bar" }, these two do exactly the same thing:

case 1a: [{ "op": "add", "path": "/baz", "value": "blarg" }]

case 1b: [{ "op": "replace", "path": "/baz", "value": "blarg" }]

Both result in { "baz": "blarg", "foo": "bar" }

While these are different:

case 2a: [{ "op": "add", "path": "/hah", "value": "blarg" }]

case 2b: [{ "op": "replace", "path": "/hah", "value": "blarg" }]

Case 2a results in { "baz": "blarg", "foo": "bar", "hah": "blarg" },
and 2b is an error.

Case 1 just seems wrong.  The "add" in 1a should be an error, and then
life would make sense.


As has already been mentioned, there are multiple tools in the box.

Stretching the analogy, having the wrench act as a hammer in some
cases does not make for a particularly well defined, robust tool box.

Barry

<Prev in Thread] Current Thread [Next in Thread>