Are there any updates on this?
One the one hand, we are hoping that this would improve some shortcomings of the current paging:
- As mentioned by Raimonds, queries with a high
startparameter are slow. Request speeds seem to indicate that when I request results 800–1000, the endpoint actually fetches pages 0–1000 to then return the last 200 of those. - Paging is sometimes unreliable. Sometimes the same object is returned multiple times on different pages, so we have to filter out duplicates by ID. Sometimes a page contains less results than what is set as the
limit, even though there are more pages. If I remember correctly, sometimes it even returns 0 results even though there are more pages.
However, we are also concerned about when this will be deployed and how much time we will have to adapt our code.
In our app, we only ever fetch the first page, or all pages in one go, so in theory we do not require backwards compatibility for using the start parameter. There is one case however where we do rely on it, and we are wondering how this will be with the new API: When expansions are paged (for example when fetching Confluence pages and expanding the labels), we currently use the specific endpoint (for example the labels endpoint) to fetch the missing pages. Will expansions provide a link with a cursor to fetch the missing pages?