Hi all, The PR has now been merged:
https://github.com/apache/ofbiz-framework/pull/1471 The REST framework in OFBiz now provides the following capabilities: - Pagination request handling - Support for pageIndex and pageSize - Support for the OFBiz-compatible aliases VIEW_INDEX and VIEW_SIZE - Default paging values and maximum page-size enforcement - Validation of malformed or invalid paging input - Filtering - Preservation of non-reserved query parameters as generic direct filter parameters - Optional endpoint validation of: - Allowed filter fields - Repeated filter values - Filter-value formats through per-field validators - Sorting - A generic sort-validation helper for comma-separated sort expressions - Support for the optional - prefix for descending order - Validation for: - Empty sort tokens - Malformed tokens, such as - - Duplicate sort fields - Unsupported sort fields when an endpoint provides an allowlist - Top-level pagination metadata - pageIndex - pageSize - totalCount - totalPages - hasNext - previousPageCount - nextPageCount - Pagination links in the response body - self - prev - next - first - last - Unavailable pagination links are omitted instead of being returned as empty placeholders - Pagination links are omitted entirely when no request path is available - Repeated non-reserved query parameters are preserved in generated pagination links - Query parameters are decoded and re-encoded when pagination links are generated - HTTP response handling - Generation of an HTTP Link header for successful paged responses - Centralized mapping of query-contract IllegalArgumentException failures to HTTP 400 Bad Request The current framework support introduced by this PR is aligned with direct query parameters such as: - Paging ?pageIndex=0&pageSize=20 - Sorting ?sort=statusId,-createdStamp - Filtering ?facilityId=WebStoreWarehouse&statusId=PRUN_CREATED The framework now supports returning 400 Bad Request when the query contract is malformed or unsupported in any of the following ways: - Invalid paging values - Malformed sort expressions - Duplicate sort fields - Unsupported sort fields when an endpoint supplies an allowlist - Unsupported filter fields when an endpoint supplies an allowlist - Repeated filter values when an endpoint does not allow repetition - Invalid filter-value formats when an endpoint supplies a validator Thanks -- Divesh Dutta www.hotwaxsystems.com On Mon, Jul 27, 2026 at 3:48 PM Divesh Dutta <[email protected]> wrote: > 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 >>>> >>>> >>>> >>>> >>>>
