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,
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.