Hi Moenieb,
thanks for reaching out.
If I understand your suggestions correctly, the current implementation
mostly supports them.
You can either expose a service through the service definition or
through the component's /api/*.rest.xml REST definition file. The latter
provides more detailed configuration options and lets you map a service
against a defined endpoint.
You find some documentation in [1] and [2].
After the migration from plugins to the framework, we will also
contribute enhanced functionality to make it more flexible and
feature-rich and provide more documentation.
See [3] for the main Jira issue and the subtasks. Most of the suggested
enhancements there are already in production in our custom projects for
quite some time.
Hope that helps.
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
[1]:
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+implement+RESTful+APIs+using+the+OFBiz+rest-api+plugin
[2]:
https://nightlies.apache.org/ofbiz/trunk/plugins/rest-api/html5/rest-api.html
[3]: https://issues.apache.org/jira/browse/OFBIZ-11328
Am 03.06.26 um 23:48 schrieb Moenieb Davids:
Hi All,
I’m really excited about this development and the change in approach. I’d
be happy to assist with performance testing or pipeline-related work if any
support is needed.
I have a question/suggestion that may already have been considered, but I
wanted to raise it for discussion.
Would it be feasible to allow a plugin to define a configuration XML
containing a list of internal OFBiz services that should be exposed through
the REST application, rather than requiring changes to the services
themselves?
For example, if I wanted to expose Party-related services such as create
and update operations, I could include a configuration file within my
plugin that specifies:
-
The internal services to expose
-
The REST endpoint paths (optional, defaulting to a standard URL pattern)
-
Supported HTTP methods (GET, POST, PUT, DELETE)
-
Request/response mappings (optional, defaulting to standard OFBiz
behavior, but allowing internal field names to be masked or sensitive
fields to be excluded)
-
Required security permissions or authentication settings
This would allow developers to expose existing OFBiz services through REST
in a configurable and modular way without modifying core application code.
It could also make it easier to package, maintain, and distribute
functionality as plugins while keeping the REST layer flexible and
extensible.
Potential benefits could include:
-
Reduced boilerplate when exposing existing services
-
Better separation between business logic and API definitions
-
Easier maintenance during OFBiz upgrades
-
Plugin-level ownership of API contracts
-
Consistent security and endpoint configuration across components
Just a thought—I'd be interested to hear whether this aligns with the
current direction and whether there are any technical or architectural
concerns that would make it difficult to implement.
On Wed, Jun 3, 2026 at 1:48 PM Lukas Finster <[email protected]>
wrote:
Hello Ashish,
Thank you for your input!
I found a way of keeping the commit history using git-filter-repo.
I will describe my approach in the corresponding Jira-Ticket if anyone
is interested.
I also changed the final destination to framework folder as you suggested.
Best regards,
Lukas
Am 03.06.26 um 12:29 schrieb Ashish Vijaywargiya:
Hello Lukas,
Thank you for your work in moving rest-api folder from plugins to
ofbiz-framework. 👏👍
I think this is what Deepak is recommending here:
Find out the history of commit logs from
https://github.com/apache/ofbiz-plugins/tree/trunk/rest-api (old
location)
and move the commit history along with the folder to the new location:
https://github.com/apache/ofbiz-framework/pull/1314/changes/2ed52de4d7b5bb4db5e320745214a9c7404f8280
.
Important Note: If you wish to move the code from the same repository,
then
it is easy to do it, just move the folder, and the version control system
should take care of rest of the part.
For example: Imagine you are moving "securityext" from the "applications"
folder to the "framework" folder, then you can easily do it. The base
folder is same:
https://github.com/apache/ofbiz-framework/tree/trunk
But you are moving the rest-api folder from plugins(
https://github.com/apache/ofbiz-plugins/tree/trunk/rest-api) to the
ofbiz-framework(https://github.com/apache/ofbiz-framework)
folder(probably
inside "framework" folder), so you need to explore how to migrate the
commit history of rest-api folder from one repo to another one.
And IMO, you should put the rest component inside the framework folder.
Here is the location where we should move the rest-api plugin.
https://github.com/apache/ofbiz-framework/tree/trunk/framework/
"applications" folder is being designed to put the business applications
like accounting, party, product, order, workeffort etc.
rest-api should be part of the "framework" folder and moved here ->
https://github.com/apache/ofbiz-framework/tree/trunk/framework.
Once you have moved the rest-api folder from plugins folder to
ofbiz-framework(inside the "framework" folder) then you can remove the
rest-api folder from plugins folder and mention the details in the OFBiz
Attic page: https://cwiki.apache.org/confluence/x/JNOoAQ
This is all I could think of on this subject.
Hopefully, it helps. 👍
--
Kind Regards,
Ashish Vijaywargiya
Vice President of Operations
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
On Tue, Jun 2, 2026 at 7:01 PM Lukas Finster <[email protected]>
wrote:
Edit:
As Deepak mentioned, we should check the possibility of preserving git
history while migrating and what the ASF approved approach ist.
Unfortunatly I could not find information regarding what the ASF
approved approach in a case like this is. Can someone point me in the
right direction?
Thank you,
Lukas
Am 02.06.26 um 15:04 schrieb Lukas Finster:
Hi everyone,
I created a pull request for migrating the rest-api plugin into
ofbiz-framework. Now I am wondering about two things:
how to go about the eventual removal of the rest-api plugin from the
ofbiz-plugin-repository. Naturaly it would be best to keep it as a
plugin for a while, to ensure people using rest are not forced to use
the latest ofbiz version containing the migration. My idea is to
already create a jira issue for its removal and link it with the
current one and tackle it at an appropriate point in time. How many
versions do you think we should still keep the old rest-plugin?
Also people using the plugin need be informed once they migrate to a
version with the migration done, as running both the old plugin and
the migrated version might cause issues. Also we don't want people
accidentaly developing on the plugin-repo version. Any ideas on how to
effectivly communicate this? Maybe there is an apropriate wiki-article
i can append this information.
Next i will tackle bringing our improvements into the rest-api as well
as the ideas that have already been mentioned (@Nicolas webapp docs i
already renamed, as it was a minor change ;)
Best regards,
Lukas
--
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
--
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
