Hi,
i am able to observe a difference in how the query parameter “limit” is handled differently among the various endpoints.
For example, when requesting the members using “GET /members” with a limit of 0, all members will be returned. Doing the same with “GET /resources” returns 10 resources (which i suppose is the default).
Another example I could find is, when requesting members without passing a value, 50 members are returned, while passing nothing to the resources endpoint returns all resources.
In my opinion, when no limit is passed, the default should be applied, and when 0 is passed all records should be returned.
Is this simply an oversight or is there a design decision behind this? I suppose changing it now will potentially break some applications so are there any plans to introduce breaking changes in a newer version of the API sometime in the future?
King regards,
Niklas
1 Like
Hey Niklas,
thank you very much for reporting this. It’s a mistake that 0 returns all records in some cases. No endpoint with potentially very large result sets should ever return unpaginated results.
We’ll have to fix this in one of the next releases so that 0 always means “default limit”, so I highly recommend not relying on this behavior. You should always check for the presence of the “Link” header in list responses and continue until done.
We generally try very hard to not break someone’s application and keep the API backwards compatible. But in this case it seems more important to keep API response times and resource usage predictable.
Hi Raphael,
thanks for clarifying!
I suggest still keeping a way to request all records at once. For example, we are currently requesting all records at once (currently by specifying 0 for /members and passing no limit to /resources) while applying filters using “from” and “until” to minimize the data returned.
I can think of two possible ways to implement such a behavior: either passing -1 to the limit or introducing another parameters like “no-limit” or “no-pagination”.
In my opinion APIs should safe developers from potential errors (like requesting all records at once) but should not constrain them when they really want to do something (even if it is potentially bad).
As I hinted, this is clearly an opinion and I am looking forward for any changes you are implementing!