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 > >
