Hi Michael, all, I added some design notes and a possible direction in OFBIZ-13457, so I will avoid repeating the details here.
At this point, I think the most useful next step is to focus on the open design questions for a generic OFBiz REST collection model, especially if we discuss pagination, sorting, and filtering. The questions I think we need to settle are: - What should be the canonical parameter names for pagination, sorting, and filtering? - Should pageIndex / pageSize be the preferred REST contract, with VIEW_INDEX / VIEW_SIZE only as compatibility aliases? - Which paging metadata should be mandatory, and which should be optional? - Should totalCount always be returned, or only when practical? - What sorting syntax should OFBiz standardize on? - What filtering syntax should OFBiz standardize on? - How much of the richer collection-query design should be required for all collection endpoints from the beginning, and how much can be phased in? For the current Manufacturing PWA I am working on, the immediate pagination need is simpler and already works with: - pageIndex - pageSize - totalCount - hasNext So from my side, the main question is how OFBiz wants to define the broader generic contract around that subset. Thanks -- Divesh Dutta www.hotwaxsystems.com On Tue, Jul 7, 2026 at 7:38 PM Divesh Dutta <[email protected]> wrote: > 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 > > > > >
