Hi Michal, all, I am testing the work in this PR <https://github.com/apache/ofbiz-framework/pull/1471> with my manufacturing based PWA apps. I plan to commit this work by the end of this week.
If any one would like to share any feedback or review, please let me know. Thanks -- Divesh Dutta www.hotwaxsystems.com On Mon, Jul 20, 2026 at 8:24 PM Divesh Dutta <[email protected]> wrote: > 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 >>> >>> >>> >>> >>>
