Thanks to clarify, Lukas. I shall then log according refactoring to my backlog in order to make my life easier and come close to the reference implementation for the PR :)
… and definitely +1 for merging this into the framework. > Am 11.06.2026 um 14:15 schrieb Lukas Finster <[email protected]>: > > Hello Carsten, > > no need for apologies, I am glad to have your input. > > Regarding proper HTTP error codes, we have locally implemented the ability to > set and overwrite the response code from within the called service in order > to return logically conditioned status codes/responses. Our company has been > using this feature for about 3 years in production environment and would > contribute it to the standard, once migration is complete. > > Leveraging swagger documentation should already be possible if im not > mistaken by providing a .rest.xml file mapping url to services and Providing > additional information to swagger. Just had a quick look, the > loadApiDefinitions in OFBizApiConfig supports this. But since there appears > to be no demo file I see how that could be confusing. Something else I will > address once migration is trough. > > Best regards, > > Lukas > > > > Am 11.06.26 um 10:36 schrieb Carsten Schinzer: >> Hello, >> >> >> Apologies to jump on this late. >> This is really a great evolution. I spent quite some time on exposing a REST >> API for a fairly small adoption of OfBiz (extending products to be Seats for >> an event like a concert along with seat maps etc.). >> >> I also truly appreciate that the PR comes with decent documentation. >> >> >> Where I have doubts is the following: >> >> - how can we leverage OpenAPI / Swagger documentation? I can see description >> and parameter documentation being possible (but who does consistently use >> service/attribute/description elements?) >> - how can we map proper HTTP protocol return codes in the 4xx range? >> >> I don’t see these are blockers to move forward, but adoption of REST APIs in >> enterprise environments w/o such features these days appears at risk. >> >> For example, in my project, this is where I spent most of the time honestly. >> In the app I mentioned, in the REST Controller classes: >> - approx. 10% of the code lines are input validation and service calls >> - approx. 40% of lines are OpenAPI annotations and >> - approx. 50% of code lines are logging, exception handling and mapping to >> proper HTTP returns. >> >> So in brief, I see the value of being able to simplify REST API exposure for >> OfBiz Services, but we need to find a way to amend the shortcomings of the >> underlying service engine with regards to documentation and return code >> mapping. >> >> Maybe I am overlooking something - I just threw a brief read into the doc on >> the PR. Then feel free to point me 🙂 >> >> Warm regards > > -- > 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 >
