Hacker News Reader

Comment by beeforpork | Hacker News Reader

Why are pointers strings? They are really multi-indexes, so why are they not arrays of strings (for hashes/"objects") and numbers (for arrays)? This would have avoided the need for escaping and for string operations in general, which complicate the whole thing.

View on HN

Quite honestly, I've yet to see an RFC with JSON in the title that isn't a disaster in one way or another.

Shorter encoding. Count the bytes:

    ["foo","bar",1,"baz","quux"]

    "/foo/bar/1/baz/quux"

It's also less parsing, and for many systems a less wieldy/less errorprone entity to pass around your runtime. You unpack it at the time you need to dereference the JSON pointer.

I guess it's more user friendly to have the path as a string, except of course most of these patches will be machine generated and processed, so the user friendliness is a bit pointless.

I think it's natural to do it this way, since it's common for a REST API to also support GETs inside objects using URLs. That is, `GET /` can return `{"top": [{"key": "value"}]}`, while `GET /top/1` can return `{"key": "value"}`. So, reusing the same syntax to refer to fields comes very naturally if you already have this support.

I don’t get this either, the byte savings are trivial and escaping/unescaping logic adds needless encoding complexity to a concept that otherwise does not need string encoders!

At Notion, we use Array<string | number> as you suggest.

partly probably just because JSON Pointer spec already exists

it's used in OpenAPI specs

apparently the goal was something that could be transferred in string contexts like a URI fragment, as well as JSON https://datatracker.ietf.org/doc/html/rfc6901#section-1

Reply on news.ycombinator.com