-
Improvement
-
Resolution: Fixed
-
Normal
-
None
-
None
-
Stats Sprint -- 2020-05-19
When I query my artist stats, I get a JSON payload of nearly a megabyte, containing 7500+ entries. That seems a waste of resources; the user is generally unlikely to want to see that many results.
On the other hand, if I specify a limit of 10, I am not told there are 7500+ entries available.
I would strongly recommend:
- adding an extra field (max_count? total?) containing the total number of available items
- defaulting the count to some documented constant (10, 40, and 100 all seem like viable music-related defaults)
- limit the range of count (0-250? 0-500?) so that users need to perform multiple (rate-limited) requests instead of being able to grab one giant payload (a count of 0 could be used just to get the max count and last-update timestamp)
Statistics Endpoints: avoid huge results
-
Improvement
-
Resolution: Fixed
-
Normal
-
None
-
None
-
Stats Sprint -- 2020-05-19
When I query my artist stats, I get a JSON payload of nearly a megabyte, containing 7500+ entries. That seems a waste of resources; the user is generally unlikely to want to see that many results.
On the other hand, if I specify a limit of 10, I am not told there are 7500+ entries available.
I would strongly recommend:
- adding an extra field (max_count? total?) containing the total number of available items
- defaulting the count to some documented constant (10, 40, and 100 all seem like viable music-related defaults)
- limit the range of count (0-250? 0-500?) so that users need to perform multiple (rate-limited) requests instead of being able to grab one giant payload (a count of 0 could be used just to get the max count and last-update timestamp)