This only distinguishes between pairable and unpairable (i.e. a matching aggregation exists in the application), rather than actually paired (i.e. a matching aggregation exists in the request), but I think that is sufficient. Most requests will come from the website, and every request from there sends filters and aggregations parameters in pairs.
A further optimisation could be to distinguish between actually paired, but I think that's not really needed right now.
https://github.com/wellcomecollection/catalogue-api/issues/677
This only distinguishes between pairable and unpairable (i.e. a matching aggregation exists in the application), rather than actually paired (i.e. a matching aggregation exists in the request), but I think that is sufficient. Most requests will come from the website, and every request from there sends filters and aggregations parameters in pairs.
A further optimisation could be to distinguish between actually paired, but I think that's not really needed right now.