+1 Thanks & Regards, Ratnesh Upadhyay
On Thu, 30 Jul 2026 at 15:50, Deepak Dixit <[email protected]> wrote: > +1 > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org > > > On Thu, Jul 30, 2026 at 3:35 PM Jacopo Cappellato < > [email protected]> wrote: > > > As a side note, one advantage of removing the export=true feature from > > the rest-api plugin is that it will make the implementation of that > > plugin simpler (because this feature requires special handling). > > > > Jacopo > > > > On Thu, Jul 30, 2026 at 10:22 AM Michael Brohl <[email protected] > > > > wrote: > > > > > > +1 > > > > > > Thanks, > > > > > > Michael Brohl > > > > > > ecomify GmbH - www.ecomify.de > > > > > > > > > Am 29.07.26 um 09:14 schrieb Mridul Pathak: > > > > I prefer the first approach. It's better to have a single way to > > expose any > > > > service as a REST endpoint through rest.xml. Those already using the > > > > current feature will need to migrate anyway. > > > > > > > > Thanks > > > > Mridul Pathak > > > > > > > > On Wed, Jul 29, 2026 at 1:29 AM Konstantinos Marinos < > > [email protected]> > > > > wrote: > > > > > > > >> Hi all, > > > >> > > > >> I was hoping to start a discussion about the current interaction of > > setting > > > >> export="true" in a service definition in regards to the recently > added > > > >> rest-api module in the framework. The same flag that existed before > > > >> (export="true") now additionally exposes a service definition as a > > REST > > > >> endpoint. This is one of the ways to create a REST endpoint (the > other > > > >> major one being a *.rest.xml definition file) but since the > component > > is > > > >> now part of the framework, this could have unintended consequences. > > > >> > > > >> My biggest concern is that developers might not immediately realise > > that > > > >> this one flag is used for similar but distinct use cases and this > > might not > > > >> be the desired behaviour for all new or previously exported > services. > > > >> > > > >> In order to avoid implicitly exposing services with potentially > > unintended > > > >> consequences, I am reaching out for your thoughts on the following > > > >> alternative actions: > > > >> > > > >> * We remove the feature of defining REST endpoints in this matter > > > >> completely. Previously existing usages of export="true" remain > > unaffected > > > >> and REST endpoints can be defined by dedicated rest.xml files. > > > >> > > > >> * We create a separate flag in the service definition (e.g. > > > >> export-api="true") that only controls the auto discovery and > creation > > of > > > >> these REST endpoints. The two export features are then decoupled > from > > each > > > >> other and by setting the new flag in the service definition, clear > > intent > > > >> is communicated by the developers. > > > >> > > > >> What do you think about these two options? > > > >> > > > >> If you are already using this feature to create REST endpoints or > > plan to > > > >> use it in the future, please let me know as well, as it would mean > > that the > > > >> second option has merit and it is the least destructive change of > the > > two. > > > >> > > > >> Thank you and best regards, > > > >> Konstantinos Marinos > > > >> > > > -- Best Regards, Ratnesh Upadhyay *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com
