←back to thread

JSON Patch

(zuplo.com)
299 points DataOverload | 10 comments | | HN request time: 0.001s | source | bottom
Show context
bsimpson ◴[] No.41881312[source]
`/` is a weird choice of delimiter for JSON.

Since JSON is a subset of JS, I would have expected `.` to be the delimiter. That jives with how people think of JSON structures in code. (Python does require bracket syntax for traversing JSON, but even pandas uses dots when you generate a dataframe from JSON.)

When I see `/`, I think:

- "This spec must have been written by backend people," and

- "I wonder if there's some relative/absolute path ambiguity they're trying to solve by making all the paths URLs."

replies(9): >>41881377 #>>41881605 #>>41881615 #>>41882491 #>>41883303 #>>41883342 #>>41885101 #>>41885337 #>>41888089 #
bityard ◴[] No.41881605[source]
Maybe we're talking about different things, but resources in REST are identified by their URL and URLs use '/' to separate elements in the path.
replies(2): >>41881871 #>>41887373 #
1. bsimpson ◴[] No.41881871[source]
Yeah, but nobody ever looked at

    {
      "a": {
        "b": {
          "c": []
        }
      }
    }
and thought "I need the list at /a/b/c"
replies(3): >>41881910 #>>41881957 #>>41882009 #
2. cjblomqvist ◴[] No.41881910[source]
If you've ever done XPath you do!
replies(1): >>41882293 #
3. bombela ◴[] No.41881957[source]
Anecdotal, I did and I do. It's no different than a path on a filesystem.
replies(1): >>41882617 #
4. maxbond ◴[] No.41882009[source]
Seems like a reasonable thing to me.

    {
      "makes": {
        "toyota": {
          "models: [ ... ]
        }
      }
    }
"I need all the models of Toyota cars."

Or

"Toyota came out with a new Camry, I need to update the Camry object within Toyota's models."

replies(2): >>41882225 #>>41884316 #
5. bsimpson ◴[] No.41882225[source]
Yeah, but that's makes.toyota.models, not /makes/toyota/models.

The point is that this is a data structure and not a web server. It's using a convention from one domain in a different one. Relatively minor in the scope of possible quibbles, but it's just one more thing to remember/one more trivial mistake to make. I'm sure much collective time will be lost to many people using dots where the spec says to use slashes, and not realizing it because it looks right in every other context with dots. Dots also makes copy/pasting easier, because you wouldn't have to migrate the format after pasting.

replies(2): >>41882298 #>>41886932 #
6. magicalhippo ◴[] No.41882293[source]
Yeah, wrote my own XPath-like extension methods to manipulate JSON just like that. Felt very natural and makes it quite easy to generate and process JSON for the cases serialization/deserialization isn't the best option.
7. maxbond ◴[] No.41882298{3}[source]
Oh I see what you mean. I misunderstood, I also don't like slash as a separator.
8. stronglikedan ◴[] No.41882617[source]
But it's different than object notation in JS, and considering JSON stands for JavaScript Object Notation, I think dot notation would have been more appropriate for JSON Pointer (and by extension JSON Path). As a bit of a rebel myself, I use dot notation when describing a location in a JSON document, unless I'm forced to use the slash for something like JSON Pointer.
9. inkyoto ◴[] No.41884316[source]
It quickly gets convoluted since Camry has been produced for more than 30 years with regular model refreshes throughout the years, e.g. 1997, 2003, 2025 etc. JSON Pointer quickly falls short since we now require a selection expression to figure out which year model we need to update in the array of models: «makes.toyota.models[?year == `2025`]» (using JMESPath).

Both, JSONPath or JMESPath, support query expressions whereas JSON Pointer does not.

10. diggan ◴[] No.41886932{3}[source]
> The point is that this is a data structure and not a web server.

URIs are not only used on web servers though, they're all over the place, probably most notable your filesystem is using `/` as a path separator, so it wouldn't be completely out of place to use it as a path separator elsewhere.