Low code platform for building business apps and workflows in minutes. Supports PostgreSQL, MySQL, MariaDB, MSSQL, MongoDB, Rest API, Docker, K8s, and more 🚀
When doing REST requests against Microsoft Graph API (used for Sharepoint, Outlook, all the other M365 applications) it sometimes limits the amount of data returned. For example, this query for retrieving list items from Sharepoint:
This API does not use the pagination mechanism that is implemented in Budibase right now. Instead, it responds with the whole link that should be followed in order to get next 'page'. In this instance, it uses @odata.nextLink variable in the results:
Depending on the endpoint, this link will have different structure and parameters, so it should be used as a whole instead of trying to extract the parameters - as explained in the API documentation.
Proposed solution:
Either add another field to the existing cursor pagination as visualized here:
where the application would choose the way of following the pages depending on what parameters are used;
When doing REST requests against Microsoft Graph API (used for Sharepoint, Outlook, all the other M365 applications) it sometimes limits the amount of data returned. For example, this query for retrieving list items from Sharepoint:
https://graph.microsoft.com/v1.0/sites/site-name/lists/list-name/items
will limit the result to 200 items. We can also limit this size further with the top parameter:
https://graph.microsoft.com/v1.0/sites/site-name/lists/list-name/items?top=50
This API does not use the pagination mechanism that is implemented in Budibase right now. Instead, it responds with the whole link that should be followed in order to get next 'page'. In this instance, it uses @odata.nextLink variable in the results:
Depending on the endpoint, this link will have different structure and parameters, so it should be used as a whole instead of trying to extract the parameters - as explained in the API documentation.
Proposed solution: Either add another field to the existing cursor pagination as visualized here: where the application would choose the way of following the pages depending on what parameters are used;
Or just create a third pagination style: