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
>
