После сна я смог заставить запрос работать в течение 5 минут с помощью JSPath (вы можете выбрать его во всплывающем окне jsonquerytool или посетить http://www.jsonquerytool.com/#/JSPath):
..a.x.{.d}
и
..b.y.{.d}
Результаты соответственно:
[
{
"d": 4,
"e": 5
}
]
и
[
{
"d": 40,
"e": 50
}
]
Мне кажется, что я нашел вариант использования, которыйJSONPath просто не может справиться, но так как это было первое, что я попробовал, у меня нет наибольшего доверия к его синтаксису запроса.
К сожалению, JSPath имеет известную ошибку / функцию с 2013 года, когда он возвращаетссылка на узел, но не на его путь, в отличие от JSONPath, который предоставляет метод jp.nodes()
, который возвращает объект {path: ..., value: ...}
, содержащий путь, который соответствует шаблону, и значение узла там. Это делает JSPath относительно бесполезным для любого реального мира.Навигация внутри большого дерева JSON (например, вид, создаваемый синтаксическими анализаторами, такими как Babylon ).
Надеюсь, знание того, где рушатся эти структуры, поможет кому-то сэкономить время, решая, какой из них использовать.У меня такое ощущение, что в настоящее время не может быть языка запросов JSON, который удовлетворял бы 2 относительно скромным потребностям: 1) сопоставление пути / значения одновременно и 2) получение пути к этим совпадениям.К сожалению, GraphQL использует конечные точки веб-сервера вместо необработанных данных, поэтому он работает на уровне 1 выше уровня.Возможно, здесь есть возможность предоставить GraphQL-подобный фреймворк, но для JSON, который также возвращает пути к результатам.