Hey @hntpx
Sincere apologies for the delayed response – this came in just as I rushed off to the mountains on leave!
In short: you raise a very valid point and I think this is good behaviour which we should clarify is desirable or at least permitted to implementors. Certainly the logic around AND
for different query parameters doesn’t preclude this, and if everyone is in agreement that this is what we want then we can get onto clarifying this in the docs as a matter of priority.
I think the desired behaviour is that AND
is used for different parameters e.g. taxonomy_id = 1 AND organization_id = XYZ
, while OR
is used for requesting values matching values within a specific parameter e.g. taxonomy_id = 1 OR taxonomy_id = 2
. As far as I’m aware, this is fairly standard practice which I would endorse supporting in the HSDS API specification.
Therefore this request:
/services?taxonomy_id=1&taxonomy_id=2
would return all services with a taxonomy_id
of 1
OR of 2
, allowing you to get all four services you list.
When querying across different parameters, each new parameter is basically an AND
clause in the logic. So this request:
/services?taxonomy_id=1&taxonomy_id=2&organization_id=XYZ
would return all services that have an organization_id
of XYZ
AND a taxonomy_id
of 1
OR 2
.
This request:
/services?taxonomy_id=1&taxonomy_id=2&organization_id=XYZ&organization_id=ABC
would return all services with an organization_id
of XYZ
OR ABC
, AND have a taxonomy_id
of 1
or 2
. This can also be represented as:
(organization_id == 'XYZ' OR organization_id == 'ABC') AND (taxonomy_id == 1 OR taxonomy_id == 2)
Would this logic work for you?
There are also some unsupported edge-cases here, but I’d need to know more about your concerns as a developer to determine whether they’re pertinent or not. The functionality outlined above would basically be the limits of the logic in this syntax, and it’d be difficult or impossible to construct more complex boolean requirements e.g.
(organization_id == 'XYZ' AND taxonomy_id == 1) OR (organization_id == 'ABC' AND taxonomy_id = 2)
I believe it’s at this point we’d need to discuss how reasonable it is to ask implementors to support query parameters in more complex formats such as a JSON payload representing the query, such as what occurs in Elastic. I’m not deeply familiar with GraphQL or JQL myself, so they might be appropriate (@rgparkins might know more about this?). In any case, the concern from the standard’s perspective would be how to represent these capabilities using the Open API specification file; as long as we have a shared way of doing that, then it should be reasonable as an approach.
There is also certainly nothing stopping any HSDS developer from also providing additional functionality, they just also need to comply with the expected behaviour outlined in the API Specification; which we’ve now got more clarity on thanks to this engagement