Show HN: SPath is a Rust lib for query JSONPath over any semi-structured data | Hacker News Reader

Show HN: SPath is a Rust lib for query JSONPath over any semi-structured data

github.com

35 pointstison10 comments

Have you looked at Jsonata? I think it is a more expressive language than jsonpath.

How is this better than just using serde_json’s ptr calls?

My guess is that users can select a query at runtime, sending it to you via http or any other text.

You could do that with the pointer methods on serde_json::Value too.

JSONPath is a full query language (https://datatracker.ietf.org/doc/rfc9535/), similar to XPath for XML. It supports things like transformations, array operations, filters, etc.

Any JSON-compatible data (and even some JavaScript data formats beyond strict JSON types) can be converted to an XML representation, have real XPath queries run on it, and the original matching data returned as the results.

We use this to great effect exploring and sifting through data in web browsers, where many different pieces of software may be storing various things globally, but you don't always know where to look.

(The advantage to this approach is that both XML and XPath are specified standards)

Here are several points I have in mind:

1. JSONPath/SPath supports multiple selector, e.g., $["a", "b"] or $[1, 3:10:2, 101]. This may be a bit more tidy than dot or subscript.

2. JSONPath/SPath supports descendant query: a descendant segment produces zero or more descendants of an input value. For example, $..[0] selects all the first element of arbitrary successors that is an array.

3. JSONPath defines filter selectors. SPath doesn't support it now, while it's on the Roadmap. This can be more powerful as a query language.

4. The original reason I wrote such a library is, however, to use JSONPath/SPath syntax beyond a JSON value. That is, I've written a database for processing semi-structured data [1], and my clients told me that's like to extract inner value with JSONPath syntax. All the existing JSONPath libraries, whether mature or not, are, of course, assuming they are handling JSON values. But in ScopeDB, we define our own variant value.

[1] https://www.scopedb.io/reference/datatypes-variant

Nice, these are all solid and I appreciate it!

Looks convenient! Do you plan to add binary?

That's a good point. Tracked at https://github.com/cratesland/spath/issues/8.

I think it would be done before I call a 1.0 release.

Reply on news.ycombinator.com