What is the rational behind the "op" property ?

[redben]

What if instead of

     [{ "op": "move", "from": "/a", "path": "/c" },
      { "op": "move", "from": "/a", "path": "/c" }]

It was

     { 
       "move": [{"from": "/a", "path": "/c"}] },
       "add": [..]
     }

I mean instead of having 1 array of all ops, its was 1 array per property type. Does it have to do with the order of operations ?

[fge]

Hello,

Well, I'm not the author of the spec so I cannot really tell, but from a purely logical standpoint, this makes sense to define it this way. What if you had two move operations to perform?

Although the following is valid JSON, its contents are undefined:

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

[huggsboson]

I am also not the author, but to echo what fge said: Objects in json aren't ordered, but usually you want your patch operations to be applied in some order.

We use this a lot to do optimistic locking on values within the object for example:

[
  { "op": "test", "path": "/foo", "value": "bar" },
  { "op": "add", "path": "/foo", "value": "baz" }
]

The spec indicates and we rely on the fact that the test operator proceeds before the add operator. If the alternative was passed:

{ 
  "test": { "path": "/foo", "value": "bar" },
  "add": { "path": "/foo", "value": "baz" }
} 

Any json parser/serializer along the way could choose to reorder the operations.

[fge]

@box-jhuffaker exactly; the JSON spec (RFC 7159) does not specify any ordering for object members nor what happens when duplicates occur. With regards to ordering, RFC 7159, section 4 explicitly states that:

JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.

By this, it shoud also be understood that implementations whose behavior does depend on order are basically left "dead in the water" -- which they should, really.

[fge]

Closing; I believe the discussion has explained pretty much why "op" exists.