Open divergentdave opened 1 year ago
Unless we're talking about tens of thousands of tasks, I'd be inclined to just say "filtering is a client-side concern" since there are any number of things api users might want to filter on. And unless there's truly more data than a client can fetch and filter with their preferred programming language, query-param-based server-side filtering tends to be awkward and is a slippery slope into "why don't we just parse a query language / graphql"
I think if/when we have pagination in place (which we currently don't because the data are likely too small to be worth it), it's not an uncommon api design thing to say "filter/order your own data on the client side"
Filtering by key may or may not be ideal, if the two deployed Collectors share collector credentials. (probably unwise, but not impossible or even all that unlikely IMO) But client-side filtering is always possible, of course.
Full-featured collectors, which hold an authentication credential for divviup-api, may want to fetch a list of DAP tasks filtered by HPKE config/collector credential identifier. This would allow them to discover tasks to collect, and ignore tasks with aggregate shares encrypted to a different collector.