Thanks Girish,
I did not have time to look into details yet but your README is very promising
:)
Jacques
Le 15/06/2020 à 17:59, Girish Vasmatkar a écrit :
Hi All
I have tried to implement a draft proposal here -
https://github.com/girishvasmatkar/ofbiz-rest-impl.git
The readme contains details.
In order to support the changes, I have made a corresponding change in the
service definition to include a new attribute named "verb". This can also
be named "method". These changes are in my forked ofbiz repo (it is very
much in sync with ofbiz trunk):
https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
Initial implementation does not contain OpenApi integration yet. And yes,
we should be fine doing both JSON and YAML.
Please take a look at it and let me know what you think of this. I am open
to suggestions, improvements, discussions.
Best Regards,
Girish
On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute <pritam.k...@hotwaxsystems.com>
wrote:
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
