jkeifer
commented
2 weeks ago The more I consider this issue the more I am convinced that the solution here is to force token-based pagination for all endpoints with user-defined behavior, and that we just need to update the backend interfaces to accept pagination arguments. I think this would be next_id and limit. The calling endpoint functions would ensure to request their pagination_limit + 1 as the limit from the backend, to be able to get the next_id and include the next link if the result set length is > pagination_limit.
I don't think it is actually important to use token-based pagination on the GET /products endpoint just for consistency, as it seems we merely need to ensure we have a next link for consistency. If we also support first/last/prev links on that endpoint it simply allows clients to leverage that additional functionality if and only if they desire to do so.
The STAPI spec documents what is expected for pagination support and in particular what endpoints should support it:
GET /productsPOST /products/{productId}/opportunitiesGET /ordersGET /orders/{orderId}/statusThe first of these is controlled entirely by the
RootRouterclass, and adding pagination to it is rather trivial. Because the set of products is not expected to vary during runtime, pagination here could leverage numbered pages (with first/last/prev/next links) because we know the total count of product records at all times (barring an uncommon service restart to add/remove products). However, adopting numbered pages for the pagination strategy here might not be consistent with the pagination strategy required by the other user-defined endpoints.For the remaining three endpoints, it is unclear to me how the backend methods used by the functions fulfilling these endpoints can support explicit arguments used for pagination such as page number or pagination token. What is more clear is if pagination is supported by these endpoints it would typically be via url parameters, and the backends currently have no way to add url parameters to the registered endpoint urls.
I understand the endpoint url paths to be regex patterns, so a wildcard pattern (excluding a
/) could potentially be used to allow extra parameters to be appended to paginated urls and still allow a match. However, it is unclear how these parameters would get passed into the endpoint functions, and further then into the backends.Another option here is to have stapi-fastapi declare the pagination strategy for all paginated endpoints by supporting a fixed set of url parameters, passing those parameters to the backend functions, and expecting the backend to return the specified set of records associated with those parameters. stapi-fastapi would then also be responsible for managing the pagination links in responses. If we were to adopt this idea, I think token-based pagination is likely the most easily supported by all backends and also the safest in the face of new records. We could also use token-based pagination for the product pages to ensure a consistent pagination mechanism across all paginated endpoints.