Hi Al, Welcome back :)
Your message has been moderated, else it would not have reached this Mailing List. Please subscribe to the dev ML. Thanks Jacques Le 10/06/2020 à 18:07, Al Byers a écrit :
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
