Think about bundle counts / totals

[slifty]

Several of our endpoints that return collections return a Bundle which includes a total number of entries (not just the amount returned). As we begin to add things like filters and user authentication this total is going to start to get a little confusing.

Currently it returns the true total number of entries in the database, NOT the total that would be available based on the filters provided. For instance, this would expose the total number of bulk uploads across ALL users, rather than just the total number of uploads for a given user.

I think this is probably an incorrect implementation.

[reefdog]

Ohh, that's a good point. So if I call a bundle endpoint with a filter, I can dictate how many results I want per page, and I can see the total number of entities in the table (excluding my filter), but I can't know if there are more results that match my filter than the _count that I indicated.

Yes this would be a good addition. To be honest I was confused by the total attribute the first time I saw it. I assumed it was basically a proxy for entries.length (which it obviously isn't). Not that that's the point here, but just as a note.

So theoretically there are four relevant totals:

• How many objects are in the table, irrespective of the filter or _count
  • Currently mapped to total, but now that we have auth scoping, this is arguably a data leak
• How many objects I'm allowed to see, irrespective of the filter or _count but bound by my auth scope
  • Currently unknowable without hitting a filter-less endpoint and paging through results
• How many objects match the current filter, irrespective of the _count
  • Currently unknowable without paging through results (or if you luck into fewer results than the _count)
• How many objects were returned by this call
  • Currently discoverable as entries.length and maybe that's good enough, but, I'll bet there's a REST spec somewhere that says you should say anyway