Hi all, Following Michael’s feedback, I did a bit more research on REST API pagination patterns so we can discuss this first from a broader framework-design perspective.
I looked at a few references, mainly: - Spring Data REST paging and sorting: https://docs.spring.io/spring-data/rest/reference/paging-and-sorting.html - Spring Data Commons pagination abstractions (Page, Slice, Pageable, PageRequest): https://docs.spring.io/spring-data/commons/reference/index.html https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/domain/PageRequest.html - GitHub REST API pagination: https://docs.github.com/rest/using-the-rest-api/using-pagination-in-the-rest-api - Stripe API pagination: https://docs.stripe.com/api/pagination - JSON:API pagination guidance: https://jsonapi.org/format/ https://jsonapi.org/examples/ - Web linking / link relation background: https://www.rfc-editor.org/info/rfc5988/ - RDAP paging metadata and paging links example: https://www.rfc-editor.org/info/rfc8977/ A few things seem especially relevant for OFBiz: 1. *Pagination is more than parameter parsing *It usually involves three parts: - how clients request a page - what paging metadata is returned - how clients navigate to the next or previous page 2. *Navigation links are widely used* Several approaches return ready-to-use next / prev links, and sometimes first / last, instead of expecting clients to rebuild paging URLs themselves. 3. *There are different response models depending on the use case* For example, Spring distinguishes between richer count-aware paging and a lighter traversal-oriented model. That seems useful for OFBiz as well, since some endpoints may want totalCount, while others may only need “is there another page?” style navigation. 4. *Different APIs make different trade-offs* - Spring tends to favor page metadata - GitHub emphasizes navigation links - Stripe uses cursor-based traversal with lighter metadata - JSON:API provides a generic structure for pagination links Based on this, I think the OFBiz discussion could focus on questions such as: - Should OFBiz start with page-number pagination, cursor pagination, or a design that can evolve toward both? - What should be the canonical request parameters for REST paging? - Should pageIndex / pageSize be preferred, with VIEW_INDEX / VIEW_SIZE kept only as compatibility aliases? - What response metadata should be standardized? - Should totalCount always be returned, or only when practical? - Should OFBiz include next / prev links in paged REST responses? - Should OFBiz distinguish between a richer count-aware response and a lighter traversal-oriented response? My current inclination is that a page-number-based model would probably be the simplest starting point for OFBiz, since it aligns well with existing conventions and current PWA needs, while still leaving room for future cursor-oriented support if needed later. I also added these notes to OFBIZ-13457 so we can continue the discussion there and shape the requirements before jumping to a framework implementation. Thanks -- Divesh Dutta www.hotwaxsystems.com
