Tuesday, September 4th, 2007
JSONPath: XPath for JSON Structures
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:
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 ~
Valuable comments above. Actually I fully agree to Jep, that talking about JSONPath “inspired by XPath†rather than “XPath for JSON†would have been much clearer and better.
I was indeed considering a short while to use xpath expressions. But it is just too hard to emulate xpath predicates, filtering and grouping. So I was orienting towards E4X syntax instead.
See as an example. E4X actually has the power of xpath and works with xml documents. So if you like E4X you would also be familiar with JSONPath. And do not disregard the benefit of powerful filter expressions as in
xpath:
//book[price>8 and pricejsonpath(js):
$..book[?(@.price>8 && @.pricejsonpath(php):
$..book[?(@['price']>8 && @['price']which do come for free by using the underlying script engine.
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.