Hi All I have tried to implement a draft proposal here - https://github.com/girishvasmatkar/ofbiz-rest-impl.git The readme contains details.
In order to support the changes, I have made a corresponding change in the service definition to include a new attribute named "verb". This can also be named "method". These changes are in my forked ofbiz repo (it is very much in sync with ofbiz trunk): https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb Initial implementation does not contain OpenApi integration yet. And yes, we should be fine doing both JSON and YAML. Please take a look at it and let me know what you think of this. I am open to suggestions, improvements, discussions. Best Regards, Girish On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute <pritam.k...@hotwaxsystems.com> wrote: > Hello Girish, > > +1 for having REST implementation using Jersey as a separate plugin and not > to disturb the OFBiz default Control servlets and filters. > > IMO we should also think about the end-point security implementations > alongside as it is one of the crucial things that users look into while > adopting any framework. > > Kind Regards, > -- > Pritam Kute > > > On Fri, Jun 12, 2020 at 2:58 PM Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > > > Hi Girish, > > > > Inline... > > > > Le 10/06/2020 à 17:42, Girish Vasmatkar a écrit : > > > Hi All > > > > > > I am again bringing up this discussion on having a REST implementation > > for > > > OFBiz. I know we have had discussions before and I was looking at some > of > > > the past discussions about this topic and seems we are not there quite > > yet > > > (correct me if I am wrong). > > > > > > I had developed a POC plug-in based on Jersey (that I am currently > > > enhancing) and recently started evaluating Apache Juneau as well. I > > wanted > > > to bring everybody on the same page as far as REST implementation is > > > concerned so I had initiated a discussion on slack today. I am listing > > down > > > a few points below that can be perceived as > > comment/question/understanding > > > based on my general understanding of the matter and today's slack > > > discussion. > > > > > > - Anything we start on can be part of a plug-in for the start and > > later > > > can become part of the framework (as separate plug-in) once it is > > > developed. A dedicated API application will allow it to be > > lightweight in > > > terms of request processing. Should have separate auth mechanism > > bypassing > > > ControlerServlet/ContextFiler/ControlFilter. I opine we do not need > > the API > > > request to go through these three. Please correct me. > > > > Though I did not look at the code (is it already somewhere?) I tend to > > agree on that. > > REST is something else and should not be hampered by those, if it's the > > case. > > > > > > > - We want to have mechanism to expose services (export=true) to be > > > available as a REST resources. Possibly extending existing service > > > definition by a new attribute verb="get|post". > > > > +1 > > > > > > > Also, if we also want to > > > expose out REST interface as an OpenApi specification, then it will > > > possibly help if we show in the spec an example of request for a > > specific > > > service. In that case, the service definition can be expanded to > > allow for > > > defining a JSON example (in a CDATA element)? > > > > That's an interesting point. Maybe we could prefer YAML over JSON. > > Because YAML is a superset of JSON and that could be useful in future: > > > > > https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json > > But it might complicate things in request bodies... > > > > > > > - Any service that declares one of the verbs and not called with > > > declared verb will result in 405(Method not found) or 404(Resource > > does not > > > exist) error. > > > - GET /api/services/{serviceName}?inParams={JSON} > > > - POST /api/services/{serviceName} (Request Body will contain in > > > params as JSON) > > > - GET /api/services : We list all services(export=true) along > with > > > HATEOS Links (self link describing where the specific service > can > > be > > > located) > > > > +1 > > > > > > > - Do we want to have a similar resource for entities?. I think > > entities > > > should not be exposed directly as a REST resource even though they > > are a > > > good example of being a resource. > > > - We can take one day at a time approach here and just start with > > > exposing services as REST. > > > > I agree, can be decided later... > > > > > > > - Auth : I had provided JWT based auth for the plug-in I had > > developed. > > > > Sounds good to me. > > > > > > > This can further be expanded and allow for Digest auth as well? Can > > have > > > separate API endpoint to generate JWT token. > > > > That could definitely be interesting. > > > > > > > > > > Please share your thoughts on this and apologies for long email. > > > > Don't apologize, perfect summary to me :) > > > > Thank you, this is long awaited and game changing feature! > > > > Jacques > > > > > > > > Best Regards, > > > Girish > > > > >
