-
Notifications
You must be signed in to change notification settings - Fork 34
Open
Description
I understand that rfc6902 is an important standard, but it's very restrictive these days.
I propose an optional mode, which provides new 'op' options that allow for much easier manipulation of JSON.
Proposal:
[
{ "op": "remove_if_exists", "path": "/a/b/c" },
{ "op": "add_if_not_exists", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "add_or_replace", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace_if_exists", "path": "/a/b/c", "value": 42 },
{ "op": "move_if_source_exists", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "move_if_target_not_exists", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy_if_source_exists", "from": "/a/b/d", "path": "/a/b/e" },
{ "op": "copy_if_target_not_exists", "from": "/a/b/d", "path": "/a/b/e" },
]
Motivation:
The current standard requires very detailed knowledge of the JSON file being processed a priori, which in many places makes processing impossible at all. This follows from point 5 in rfc6902:
If a normative requirement is violated by a JSON Patch document, or
if an operation is not successful, evaluation of the JSON Patch
document SHOULD terminate and application of the entire patch
document SHALL NOT be deemed successful.
What do you think?
Metadata
Metadata
Assignees
Labels
No labels