So JSON-API apparently left the world to it's own devices when it came up with the concept of "filters" without defining any idea of what the structure for these should look like. As a result, our existing JSON-API applications use the following style for filtering resources:
For example, to search for users between the ages of 24 and 45:
/users?filter[age][$gte]=24&filter[age][$lte]=45
In KurierJS, this would instead look like:
/users?filter[age]=ge:24&filter[age]=le:45
Both are in total compliance with the spec and obviously I have no desire to ask that KurierJS conform to how our existing application stack works today. However, it would be awesome if we could leverage KurierJS in our applications going forward while still maintaining compatibility with how our other applications work, especially since our frontends are all designed to work around that style of querying. If there was a way to inject a new filter parser into the Application, that would resolve our issue perfectly.
This isn't blocking us; currently the former gets read in and it mangles the keys a bit, but it works and I can convert it into a more readable format. But it's definitely not ideal and could be cleaner.
So JSON-API apparently left the world to it's own devices when it came up with the concept of "filters" without defining any idea of what the structure for these should look like. As a result, our existing JSON-API applications use the following style for filtering resources:
/resource?filter[field1][$op]=value1&[field][$op]=value2For example, to search for users between the ages of 24 and 45:
/users?filter[age][$gte]=24&filter[age][$lte]=45In KurierJS, this would instead look like:
/users?filter[age]=ge:24&filter[age]=le:45Both are in total compliance with the spec and obviously I have no desire to ask that KurierJS conform to how our existing application stack works today. However, it would be awesome if we could leverage KurierJS in our applications going forward while still maintaining compatibility with how our other applications work, especially since our frontends are all designed to work around that style of querying. If there was a way to inject a new filter parser into the Application, that would resolve our issue perfectly.
This isn't blocking us; currently the former gets read in and it mangles the keys a bit, but it works and I can convert it into a more readable format. But it's definitely not ideal and could be cleaner.