Tuesday, September 4th, 2007
JSONPath: XPath for JSON Structures
<p>Stefan Gössner thought that there should be a benefit in having some kind of XPath4JSON. He ended up creating JSONPath, "a lightweight component that allows to find and extract relevant portions out of JSON structures on the client as well as on the server."Given the JSON structure:
JSON:
-
{ "store": {
"book": [
{ "category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95
},
{ "category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99
{ "category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99
}
],
"bicycle": {
"color": "red",
"price": 19.95
}
}
}
You could query data out such as:
Related Content:
4 rating from 25 votes
Nice, but why not use xpath expressions?
Apache JXPath did this for Java. Basically you can apply XPath expressions to trees of objects in addition to XML documents. Quite useful.
I like it, it’s easier to remember for programmers.
has like an E4x flavour…
Has anyone been able to get the Javascript example working?
Sounds like a pretty useful idea. Nice.
Argh. Why not use XPath? It’s standard and you’ll probably use it somewhere else sometime. Don’t clutter your brain with yet another syntax.
I like the concept, but I agree it would have been better to use the XPath syntax.
Agree that it would be better to use the XPath syntax. However, it does make more sense to combine XPath with XML data instead of JSON. So maybe Stefan should just call JSONPath “inspired by XPath” rather than “XPath for JSON”: then the different syntax doesn’t matter, as long as it works. That also avoids the pitfall of partial XPath support, because complete XPath is a lot of work (we’ve done that at Backbase)
Great minds think alike:
I posted a blog a while back (http://www.json.com/2007/03/14/xml-is-dead-long-live-xml/ ) that we were working on something similar: jsPath .
I agree that xPath already well used and damn hard to support the full syntax. The reason we modeled jsPath on xPath is because of how mature it is.
On the other hand, jsPath can work on the client without loading XML. The other benefit: you can define your own lamdas! If you want to create your a function to sum across multiple elements of different hierarchies – you can do it in javaScript yourself! There is no need to mess around with creating keys just so you can do cross node sets.
it’s really a good way to define a navigation language for JSON, but looks like the points showed above just contain a little of it ~
JSONPath is a bit of a misnomer, apparently closely modeled atop E4X, not XPath. E4X, in turn, was modeled on what would be the sweet spot of similarity to ecmascript syntax and the power of XPath succinctness, in an XML context. Replace “XML” for “JSON” there, and you have JSONPath, that might better have been named “E4J”, which no doubt was already heavily overloaded by other meanings, and would be known and grokked by far fewer devs today.
It’s a cool tool, though.
Pot. Kettle. Black. XML and XPath are the ‘cluttered’ syntax, not JSONPath. From TFA:
The point is that JSONPath is MORE intuitive, because it uses the dot, bracket, and lambda notation that every programmer knows. It doesn’t muck things up like XPath and XML do.