Нет, я не думаю, что вы что-то упускаете.
Проблема в отсутствии истинного стандарта для JSONPath.Есть несколько идей / предложений (в том числе несколько связанных с JSON Pointer , которые в течение нескольких лет застряли в фазе «ПРЕДЛАГАЕМЫЙ СТАНДАРТ»), много реализаций, и все они каким-то образом отличаются дажекогда они предположительно реализуют одно и то же предложение (например, одно Стефана Гесснера ).
Например, при использовании Jayway JsonPath , эти выражения JSONPath
$.[?(@.methodresult == 'error')]
$[?(@.methodresult == 'error')]
.[?(@.methodresult == 'error')]
[?(@.methodresult == 'error')]
выдает тот же результат для входного JSON из вопроса:
{
"methodresult": "error",
"ErrorCode": 2,
"ErrorCodeText": "format",
"ErrorMessage": "Json parse exception at pos:171 msg:Expecting \"key\""
}
Они возвращают непустой массив, содержащий объект JSON с полем methodresult
, равным error
.И этого следует ожидать, если взглянуть на предложение Стефана Гесснера ...
Попытка тех же выражений для заданного ввода здесь (ссылка в вопросе) или здесь (который предлагает запустить заданное выражение JSONPath с использованием 4 различных реализаций), и результаты будут смешанными: неудачный анализ, ошибки выполнения, пустой массив и иногда, как и ожидалось.
Суть в том, чтопока не будет истинного стандарта для JSONPath, единственный способ убедиться, что выражение JSONPath работает должным образом, - это записать его для реализации concrete JSONPath, которую вы будете использовать в своем приложении.