Or should be that be JsonPath? Whatever, it’s a tool I’ve been using lately and generally like. But it could use a little work.
The last project I worked on, Step Functions, has a JSON DSL for State Machines, which makes use of JSONPath (see Paths and Input and Output Procesing) to solve a tricky problem in a way that people seem to find easy to understand and use.
Early on in that project we adopted the Jayway JsonPath library and it seems to mostly Just Work.
But, we’ve had a few questions from customer along the lines of “Your service rejected my InputPath, but it looks OK to me.”
Which raises the question: What is a legal JsonPath, anyhow?
To the extent there’s an “official” definition, the most obvious candidate would be Stefan Goessner’s JSONPath - XPath for JSON. Standards wonks will sneer at it, not a shred of BNF in sight. But I like it, because it applies the most important lesson from Mark Pilgrim’s immortal Morons and Assholes essay: Have lots of examples.
Having said that, it’s kind of skinny. And if you go back to that Jayway JsonPath spec and start scrolling the README.md, well, you can keep scrolling and scrolling, and there’s a lot of goodness there.
But still, is $.blog-entry a valid JSONPath? Or should you
have to say $['blog-entry']? Because blog-entry is not,
after all, a JavaScript “Name” construct.
For the purposes of AWS Step Functions, JsonPath means what Jayway says it means. But I’d be happier if there were an RFC or something because, good as Jayway is, people do [*gasp*] write code in languages other than Java.
So, an RFC maybe? The idea’s not crazy.
Capitalization · Let me settle one dispute right here: Stefan Goessner says “JSONPath”, Jayway says “JsonPath”. Stefan’s right, because it’s called JSON not Json, and by the analogy with XPath.
Contributions
Comment feed for ongoing:
From: Bob Monsour (Apr 14 2017, at 10:27)
Pardon me for being an asshole at the moment, but the 2nd link for the Jayway JsonPath is coughing. The first one works beautifully.
[link]
From: anonymous (Apr 14 2017, at 10:53)
There is JSON Pointer (RFC 6901), but it's a lot less powerful than XPath or JsonPath, and I'm not aware of any mainstream usage of that spec.
[link]
From: Jilles van Gurp (Apr 14 2017, at 11:40)
I've been using a command line tool called jq a lot lately to pick apart json that comes back from AWS. I guess that's pretty close to having xpath like support for json already.
For example this nice one liner dumps the names of the various stacks we have running with cloud formation:
aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --stack-status-filter UPDATE_COMPLETE --max-items 100 | jq --raw-output '.StackSummaries[].StackName'
Very useful if you have to deal with big blobs of json coming from wherever.
[link]
From: Clayton Coleman (Apr 14 2017, at 13:48)
A formal spec for JSONPath would be very useful. For Kubernetes we have a strong desire to use JSONPath for adhoc referential integrity and loose coupling between resources, but the lack of a formal spec has meant we have been cautious about its use. We would be eager consumers of a formal spec and work to provide a Go library (which we have informally today).
[link]
From: Marcus Ramberg (Apr 15 2017, at 23:08)
The Mojolicious web framework implements JSON pointer support: http://mojolicious.org/perldoc/Mojo/JSON/Pointer
We would really like it if a more powerful mechanism was standardized though.
[link]
From: Sylvie (Apr 18 2017, at 13:12)
+1 to Jilles van Gurp's comment: "jq" is awesome.
I needed to extract the "id" attribute from one of these:
{
"size": 6,
"limit": 25,
"isLastPage": true,
"values": [
{
"id": 504,
"type": "read-only",
"matcher": {
"id": "development",
"displayId": "Development",
"type": {
"id": "MODEL_BRANCH",
"name": "Branching model branch"
},
"active": true
},
"users": [],
"groups": [],
"accessKeys": []
},{}]}
Here was the jq query for that:
'.values[] | select(.type=="read-only" and .matcher.id=="development") | .id '
Out pops 504 ! :-D
[link]