Hi Al, Great to see you still present.
Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer Apache Steve <https://steve.apache.org>, committer On Wed, Jun 10, 2020 at 6:19 PM Al Byers <bye...@gmail.com> wrote: > I am curious as to whether or not you have looked at what Moqui has done? > I'm not up to speed on it enough to comment on how it stacks up against > your list, but it seems logical to look at it since OFBiz and Moqui share a > lot of DNA. > > Al Byers > > On Wed, Jun 10, 2020 at 9:43 AM Girish Vasmatkar < > girish.vasmat...@hotwaxsystems.com> wrote: > > > 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. > > - 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". 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)? > > - 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) > > - 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. > > - Auth : I had provided JWT based auth for the plug-in I had > developed. > > This can further be expanded and allow for Digest auth as well? Can > have > > separate API endpoint to generate JWT token. > > > > Please share your thoughts on this and apologies for long email. > > > > Best Regards, > > Girish > > >
