Go: proposal: encoding/json: add EvalJSONPointer function to support RFC 6901

[baijum]

RFC 6901 describes the JSON Pointer standard.

JSON Pointer defines a string syntax for identifying a specific value within a JSON document.

More advanced query languages like JSONPath and JMESPath is not required in many cases. Also including it as part of the standard library would be an overkill.

Since JSON Pointer is a small standard, the implementation would be easy.

The API could be something like this:

func EvalJSONPointer(v interface{}, format string) ([]byte, error) {...}

[Merovius]

I think the API needs a bit of work. AIUI it takes an arbitrary Go value and returns a []byte - so is the intent that it marshals the referenced value into JSON? ISTM that it would be more useful to return the value as a Go value. But that mainly depends on how people would want to use it - there might even be a need for different function signatures, to do different things. In particular, the RFC poses two questions that need answers: 1. How is - handled and 2. how are errors handled? Again - we might need different answers for different use-cases.

Given that, as far as I can see, nothing in the stdlib benefits from this and the implementation also doesn't benefit from coupling with internal stdlib code, I think the best course of action here is to implement this outside the stdlib to experiment with the API and re-consider the benefits of including it once kinks in the API has been shaken out.

[mvdan]

I agree with Axel; implement this outside of the standard library first. https://golang.org/doc/faq#x_in_std

[baijum]

I agree with Axel; implement this outside of the standard library first. https://golang.org/doc/faq#x_in_std

On a quick search, I found these implementations with different API:

1. https://github.com/dolmen-go/jsonptr
2. https://github.com/qri-io/jsonpointer
3. https://github.com/go-openapi/jsonpointer
4. https://github.com/dustin/go-jsonpointer
5. https://github.com/xeipuuv/gojsonpointer
6. https://github.com/yukithm/json2csv/tree/master/jsonpointer
7. https://github.com/json-validate/json-pointer-go
8. https://github.com/twindagger/jsonptr
9. https://github.com/rnd42/go-jsonpointer
10. https://github.com/lestrrat-go/jspointer

Edit 1: Added one more implementation (jsonptr)
Edit 2: Added 4 more implementations

[rsc]

encoding/json does support a generic JSON representation - map[string]interface{} - but it's not really the most efficient or preferred implementation most of the time. Would jsonpointer have to work on every possible struct that can be marshaled or unmarshaled with the json package?

Also, how commonly used is this? Why not keep using one of the choices outside the standard library?

[dolmen]

As the author of package github.com/dolmen-go/jsonptr I don't think there is a need for a JSON Pointer implementation inside the stdlib. An implementation inside the stdlib would not be easier than any external one. The only valid reason for an stdlib implementation would be to reduce fragmentation by directing most users of JSON Pointer towards the use of that implementation.

@rsc wrote:

encoding/json does support a generic JSON representation - map[string]interface{} - but it's not really the most efficient or preferred implementation most of the time. Would jsonpointer have to work on every possible struct that can be marshaled or unmarshaled with the json package?

An under-documented feature of my own implementation is that it supports not just trees of []interface{} and map[string]interface{} as input document, but also json.RawMessage and any value implementing interface JSONDecoder (a subset of encoding/json.Decoder API). This allows much flexibility for input. However the same flexibility isn't offered for jsonptr.Set because of writability constraints.

[dolmen]

I've also published a framework for benchmarking Go implementations of JSON Pointer here:
https://github.com/dolmen-go/jsonptr-benchmark

[rsc]

Based on the discussion above, this seems like a likely decline.

[rsc]

No change in consensus, so declined.