How to Use JSON Path

One of the best tools I&#x27;ve found for manipulating JSON via JsonPath syntax is <a href="https:&#x2F;&#x2F;jsonata.org" rel="nofollow">https:&#x2F;&#x2F;jsonata.org</a><p>In addition to simple queries that allow you to select one (or multiple) matching nodes, it also provides some helper functions, such as arithmetic, comparisons, sorting, grouping, datetime manipulation, and aggregation (e.g. sum, max, min).<p>It&#x27;s written in JS and can be used in Node or in the browser, and there&#x27;s also a Python wrapper: <a href="https:&#x2F;&#x2F;pypi.org&#x2F;project&#x2F;pyjsonata&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pypi.org&#x2F;project&#x2F;pyjsonata&#x2F;</a>

Not sure if this is a common problem, but I built a tool to help me quickly understand the main schema, and where most of the data is, for a new JSON file given to me. It makes the assumption that sometimes peer elements in a list will have the same structure (eg they&#x27;ll be objects with similar sets of keys). If that&#x27;s true, it learns the structure of the file, prints out the heaviest _aggregated_ path (meaning it thinks in terms of a directory-like structure), as well as giving you various size-per-path hints to help introduce yourself to the JSON file:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;tylerneylon&#x2F;json_profile">https:&#x2F;&#x2F;github.com&#x2F;tylerneylon&#x2F;json_profile</a>

Is there a general name for the kind of data structure JSON represents?<p>We see this kind of Nete’s data all over the place (json, yaml, python dictionaries, toml, etc, etc) and I’m thinking wouldn’t it be nice if we had a path language that worked across these structures, just like how we can regex any strings?<p>So we can have a pathql executable that we can feed yaml and json data to, but I can reuse the query in Python when I want to extract values from a json stream I just deserialized.

In the past I&#x27;ve used XPath, and CSS selectors using this library to filter and find data in JSON: <a href="https:&#x2F;&#x2F;github.com&#x2F;tomhodgins&#x2F;espath">https:&#x2F;&#x2F;github.com&#x2F;tomhodgins&#x2F;espath</a><p>The approach is to take the JavaScript object, convert it to XML DOM, run the query (either using standard XPath, or standard CSS selectors) and then either convert the DOM back into objects, or another way I&#x27;ve seen it done is to keep a register of the original objects and retrieve the original objects.<p>In this way, JSON, and any JavaScript object with non-circularity can be sifted and searched and filtered in reliable ways using already-standardized methods just by using those technologies together in a fun new way.<p>There is not necessarily a need for inventing a new custom syntax&#x2F;DSL for querying unless you don&#x27;t want to make use of CSS and XPath, or have very specific needs.

SQLite includes a subset of JSON Path in the core database these days, used by functions like json_extract()<p>I wrote up my own detailed notes on that subset a while ago: <a href="https:&#x2F;&#x2F;til.simonwillison.net&#x2F;sqlite&#x2F;json-extract-path" rel="nofollow">https:&#x2F;&#x2F;til.simonwillison.net&#x2F;sqlite&#x2F;json-extract-path</a>

I&#x27;ve used postgresql&#x27;s jsonpath support to create user defined filtering rules on db rows. It made things a lot easier than whatever other methods I could come up with.

Insomnia and Bruno has a feature to filter the responses using JSON Path. It&#x27;s really useful.

Is the necessity of tools like JSON Path really just an indication that APIs are increasingly returning too much junk and &#x2F; or way more data than the client actually requested and &#x2F; or needs?<p>In dev mode, our internal APIs return pretty printed JSON so one can inspect via view-source, more, or text editor.

I look forward to the inevitable JSON path injection attacks given how widespread XPATH injection used to be. ( See <a href="https:&#x2F;&#x2F;owasp.org&#x2F;www-community&#x2F;attacks&#x2F;XPATH_Injection" rel="nofollow">https:&#x2F;&#x2F;owasp.org&#x2F;www-community&#x2F;attacks&#x2F;XPATH_Injection</a> for more info. )

JSONPath is good when it comes to querying large JSON documents. But in my opinion, more than this is the need to simplify reading and writing from JSON documents. We use POJOs &#x2F; model classes which can become a chore for large JSON documents. While it is possible to read paths, I had not seen any tool using which we could read and write JSON paths in a document without using POJOs. And so I wrote unify-jdocs - read and write any JSON path with a single line of code without ever using POJOs. And also use model documents to replace JSONSchema. You can find this library here -&gt; <a href="https:&#x2F;&#x2F;github.com&#x2F;americanexpress&#x2F;unify-jdocs">https:&#x2F;&#x2F;github.com&#x2F;americanexpress&#x2F;unify-jdocs</a>.

I am kind of surprised that they don&#x27;t mention jq at all, it seems like a similar tool that is fairly wide spread.

kubectl has JSON Path support built in, it’s very useful<p><a href="https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;reference&#x2F;kubectl&#x2F;jsonpath&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;reference&#x2F;kubectl&#x2F;jsonpath&#x2F;</a>

I wish there weren’t so many JSON path syntaxes. I’m comfortable with jq, then there’s JSON path, I forget which one AWS CLI is using, MySQL has their own. It’s impossible for me to get muscle memory with any of them.

Has anyone had performance issues using JSONPath? We are processing large pieces of data per request in a node express service and we believe JSONPath is causing our service to lock up and slow down. We’ve seen the issue improve as we have started refactoring out JSONPath usage for vanilla iteration and conditional checks.<p>There are a lot of factors at play so we can’t quite put our thumb on JSONPath, but it’s the current suspect and curious if others have run into anything similar.

This is exactly the type of thing that LLMs are very good at generating and explaining for you. I&#x27;ve done this countless times to create and understand regex patterns.

We&#x27;re using JSONPath to annotate parts of JSON fields in PostgreSQL that need to be extracted&#x2F;replaced for localization. Whilst I&#x27;d naturally prefer we didn&#x27;t store display copy in these structures, it was a fun thing to implement.<p>Contrived example:<p><pre><code> @localizedModel({ title: {}, quiz: { jsonPath: &#x27;$.[question,answerMd]&#x27; }, }) class MyQuiz { title: string; quiz: JSONObject; }</code></pre>

1. Create a mock json document that has the structure you are trying to query.<p>2. Ask [newest LLM] to write the proper json path to get to the element you want to reach.

I&#x27;ve used JSONPath in a small side project that was supposed to be a linter for TypeScript with JSONPath querying over the abstract.syntax tree:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Tade0&#x2F;permit-a38&#x2F;tree&#x2F;master">https:&#x2F;&#x2F;github.com&#x2F;Tade0&#x2F;permit-a38&#x2F;tree&#x2F;master</a><p>Ultimately the linting rules proved to be easier to write than read.

Alternative: use jless and copy the path of the thing you want, then (maybe) generailze

If you&#x27;re on a Mac, OK JSON is a tremendous aid in working with documents and includes a decent JSONPath query dialog. (Very happy user)<p><a href="https:&#x2F;&#x2F;okjson.app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;okjson.app&#x2F;</a>

These types of languages are a bad idea, just as XPath was. They are complex enough to be a maintenance&#x2F;bug risk AND don&#x27;t bring any additional benefit to just writing code in your normal programming language to do the same thing.<p>You can take my list comprehensions from my cold, dead hands.<p>There isn&#x27;t a use case I&#x27;ve seen where these types of mini languages fit well. Ostensibly, you could give it to a user to write to query JSON in a domain-agnostic way in an app but I think it would just confuse most users <i>as well</i> as not being powerful enough for half of their use cases.<p>Sometimes it&#x27;s better just to write code.

there is possibly a need for more unified standard across different implementations particularly from a software development and API design perspective.<p>During parsing and manipulation of JSON data, the syntactical discrepancies&#x2F;behaviours between various libraries might need a common specification, for interoperability.<p>features like type-aware queries or schema validation, may be very helpful.