+1 Lukas! -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com
On Tue, Jul 28, 2026 at 3:32 PM Lukas Finster <[email protected]> wrote: > Hi Divesh, > > setting export="true" on a service and exposing it via > <my-component>/api/<rest-file-name>.rest.xml effectivly achieves the > same thing from a REST point of view. > > I don't now if there are other sideeffects of using export="true" in the > service.xml. If your only goal is to expose a service as a REST > endpoint, I would suggest sticking to the .rest.xml definition, as this > should be regarded as the default option for what you are trying to do > now with rest-api in the framework in my opinion. It is not neccessary > to do both. > > Asside from that your plan reads good to me. > > Best regards, > > Lukas > > > Am 28.07.26 um 11:33 schrieb Divesh Dutta: > > Hi all, > > > > As I am working on Manufacturing related APIs for the Manufacturing > > application, covering areas such as BOM, routing, production runs and > MRP, > > and I would like to confirm the preferred approach before finalizing the > > patches. > > > > The proposed approach is to add REST API definitions in the Manufacturing > > component and expose the required services from the component itself. > This > > would include: > > > > - adding new read/fetch services with export="true" for REST API > usage, > > - adding explicit permission-service definitions to those exported > > services, > > - changing a small number of existing mutation services to > export="true" so > > they can be used by REST APIs, > > - adding permission services to those existing mutation services as > well. > > > > The intent is to keep the REST API close to the application component > that > > owns the business behavior, instead of creating a separate layer outside > > the component for these APIs. > > > > For example, in Manufacturing this could mean services for BOM, routing, > > and MRP workflows are defined and secured in Manufacturing service > > definition files, with REST mappings in > applications/manufacturing/api/.... > > > > Since OFBiz application components do not currently have much REST API > code > > directly inside them, I wanted to ask whether this is an acceptable > > direction for upstream contributions. > > > > The questions I would like to confirm are: > > > > 1. Is it acceptable to introduce REST-facing services with > > export="true" directly > > in an application component such as Manufacturing? > > 2. Is it acceptable to mark existing application services as > > export="true" when they are intended to be called through REST, > provided > > we also add explicit permission services? > > 3. I plan to add read/fetch services used by REST/UI workflows > directly > > in the owning application component. Does this align with OFBiz’s > preferred > > component boundaries? > > 4. Are there any concerns with adding api/*.rest.xml descriptors > > directly under application components? > > 5. Is there anything else I should account for before adding the > first > > component-owned REST API contribution? > > > > My current thinking is that this should be okay as long as the services > are > > component-owned, explicitly permissioned, and reuse existing OFBiz > business > > logic rather than bypassing it. But I wanted to check with the community > > before proceeding further. > > > > Thanks > > > > -- > > Divesh Dutta > > > > www.hotwaxsystems.com > > > -- > Lukas Finster > Softwareentwickler & Berater > > ecomify GmbH, Stralsunder Straße 63, 33605 Bielefeld > Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de > Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin Becker, > Michael Brohl > >
