change link removal example to be "set-like" rather than "array-like" #99
Conversation
change link removal example to be "set-like" rather than "array-like"
|
Thank you ! This is more motivation for me to change the way we discuss JSON PATCH in this spec; we shouldn't need to re-iterate it's rules here. Haven't gotten to it yet. |
|
The difficulty here is more JSON Pointer which is what JSON Patch uses for the operation path. |
|
@guillec I agree this is a limitation, though I'm not sure that either spec is exactly "at fault": to be able to reference array elements by value, JSON Pointer would have to evolve more into a query API, which seems somewhat outside it's intended scope. The JSON patch spec could define this "set-like behavior", but it doesn't, so JSON API should clarify it (hence #100 ). As I mentioned, it seems "set-like" objects are represented as an array when read and added to (only via appending), but treated more as an object (with the array elements as both key names and values) when updated. I see you're running up against somewhat similar limitations with #91 . Again there, I'm not sure that sticking strictly within the JSON Patch/Pointer specs is the best approach. |
|
Yup it all makes sense, as I was editing the paths on #91 I was following the JSON Patch/Pointer specs. I agree, strictly sticking within the JSON Patch/Pointer specs might not be the best solution here. |
|
If the JSON PATCH spec can't handle something, it's a bug in that spec. We shouldn't be extending another RFC unless we absolutely have to. |
|
... specifically because we don't have jurisdiction to. If you send a request with the |
The example of "removing comment 5 from this photo" uses "/photos/0/links/comments/1" as it's path. That references the array index of the comment in it's collection, treating it like an array, however the surrounding text explicitly states that "to-many relationships have set-like behavior in JSON API"
This set-like behavior isn't really defined (I don't see it mentioned anywhere in the JSON Patch RFC ), but it seems like it should mean "values are returned as an array, but the items in that array should be treated as though they were object keys with ignorable values". Basically, the order of that array should be explicitly ignored, and references should be by ID rather that array index.
This would to imply that the example should be "/photos/0/links/comments/5" (by ID -- it's a set, not by array index)