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
