Hi Michael, all, As a follow-up, I have opened a draft PR for the generic framework-side REST collection query support:
https://github.com/apache/ofbiz-framework/pull/1471 I have also added a summary of what is included in this round, along with what is still left for future work, in the related Jira ticket: https://issues.apache.org/jira/browse/OFBIZ-13457 The PR focuses on reusable framework support in framework/rest-api. My thought is that this can serve as a practical first step for the common paging/sorting/filtering mechanics, and future enhancements options can continue to be discussed in Jira and on the dev list. I request Michael and others to look at the PR and share the feedback. Thanks -- Divesh Dutta www.hotwaxsystems.com On Wed, Jul 15, 2026 at 12:17 PM Divesh Dutta < [email protected]> wrote: > 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 >> >> >> >> >>
