This is a bit unusual issue, it's not about coding, but about doing research.
We're currently using yalp/jsonpath as JSONPath backend. It works well, however the author stated in README that it's experimental and users should switch to another engines.
Here are some other engines that I've found:
ojg looks promising, but to proceed, we need to compare it with yalp/jsonpath.
Ideally, we need two things:
- a table of JSONPAth syntax features that summarizes what is supported and not by
yalp/jsonpath and ojg
- two test sets: one is a list of queries that work exactly the same for both parsers; one is a list of queries that work differently (e.g. one of the parser fails or maybe they return different results)
After we'll have this, we can decide whether it's possible to switch without breaking compatibility, and if not, we'll be able to provide migration guide for users.
We already have a test that covers many queries, though likely not all of them: https://github.com/gavv/httpexpect/blob/master/value_test.go#L441
Previous discussion: #49
Useful materials:
This is a bit unusual issue, it's not about coding, but about doing research.
We're currently using yalp/jsonpath as JSONPath backend. It works well, however the author stated in README that it's experimental and users should switch to another engines.
Here are some other engines that I've found:
ojglooks promising, but to proceed, we need to compare it withyalp/jsonpath.Ideally, we need two things:
yalp/jsonpathandojgAfter we'll have this, we can decide whether it's possible to switch without breaking compatibility, and if not, we'll be able to provide migration guide for users.
We already have a test that covers many queries, though likely not all of them: https://github.com/gavv/httpexpect/blob/master/value_test.go#L441
Previous discussion: #49
Useful materials: