[Feature Request] Use jq for JSON filters

[champo]

JSON filters on Insomnia are pretty useful, but there's some cases that aren't (nicely) covered by it. I have to regularly interact with APIs that return arrays of big JSON objects (40+ properties) of which I usually need a small subset of fields. JSON path allows you to do $.results[*]["asd","id"] but that prints an array with no keys which is confusing when the types of the fields are similar.

jq is really powerfull JSON processor which can transform just about any JSON input to any output you can imagine (while being really really fast). The query .results[] | {asd, id} would produce an array of objects with the proper keys, instead of simply the values.

[welcome]

👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kud]

Hello!

I'm using Insomnia at this moment and yeah I was surprised it's JSONPath which is used where https://stedolan.github.io/jq/ sounds to be a real competitor here.

I already use jq inside Sublime Text and it works like a charm!

It should be considered by the Insomnia Team. :)

Could we reopen this issue?

[js-mode]

I attempted to write a plugin that would use jq instead of JSONPath, but there were errors because jsonpath is so integrated throughout Insomnia.

Wish we could have the option to switch between both jq or jsonpath. If you look at this plugin it is importing the JSONpath module here.

Would be nice if we could actually require node-jq and pass in jq queries to filter responses. @gschier - is this something that is feasible or would it require a lot more rework since the response filter is hardcoded for jsonpath?

Also I opened this issue here regarding adding environment variables to the filter input box beneath the response. Seems like these two items would really be useful if we could get it implemented?

[supersexy]

Another jq fan - I would like to add that it would be great to have the curl code generator produce valid code for jq optionally!

[supersexy]

maybe helpful: https://github.com/stedolan/jq/wiki/For-JSONPath-users

[dimitropoulos]

I'm gonna resurrect this and commandeer it for keeping track of these things.

In my mind, since the jsonpath libraries have mostly been abandoned since the time they were first introduced into insomnia and jq has since come a long way, I think this is a viable thing to explore now.

[dimitropoulos]

current issues that this would solve include:

1. Filtering all the keys not working #3258
2. JSONpath evaluator not working as expected #2342
3. JSONPath array filter can't refer to root object ($) #3155

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[admodras]

would like to keep this issue open if at all possible. There has been a larger need to be able to use JQ within insomnia and think this would be an extremely valuable addition to this product.

[technodrome]

3 years, 7 months and still open. It amazes me such obviously useful features need to take this long to "mature" for the devs to actually notice.

[kud]

PR are welcome.

[js-mode]

First step here is the ability to save a response as a variable.

Similar to how postman let's you just write JavaScript code to parse the response data because each response is automatically stored as a variable.

If we could somehow have an object that is storing the request and response with some sort of timestamp, then it would be easier to implement some form of jq extension to used against this object.

I personally would love to help implement this feature, but there's just to much involved in other areas of the code I'm not familiar with.

Greg originally said this would be pretty easy to implement years ago but then as he started to dig in, it turned out it was way more complicated than envisioned.

My suggestion would be to somehow start small and allow the response to be stored as a variable behind the scenes and then allow for some external pop-up window that will allow you to write custom parsing functions against that variable.

[kobenguyent]

@js-mode may you give it a try? #6539