@daliwali I believe my suggested approach is compliant with 6902, although the spec seems somewhat open to interpretation:

Additionally, operation objects MUST have exactly one "path" member.
That member's value is a string containing a JSON-Pointer value
[RFC6901] that references a location within the target document (the
"target location") where the operation is performed.

The question comes down to what is considered to be the target document of a JSON Patch operation. The current examples in JSON API consider the target document to be the response document from a GET request to the same path, in which arrays are accessed by position instead of as a set keyed by id.

However, I find it much more appropriate (and consistent with other requests) to operate on the target document discussed in #193.

The following example from 6902 is consistent with this approach (or at least, doesn't contradict it):

   PATCH /my/data HTTP/1.1
   Host: example.org
   Content-Length: 326
   Content-Type: application/json-patch+json
   If-Match: "abc123"

   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

The PATCH is issued against /my/data and the paths for each operation in the request document are clearly relative to the request path, in that they don't repeat it.

Patch operation path #225

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.