You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Girish Vasmatkar <gi...@hotwaxsystems.com> on 2020/06/10 15:42:17 UTC
REST implementation
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
Re: REST implementation
Posted by Pierre Smits <pi...@apache.org>.
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 <by...@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.vasmatkar@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
> >
>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.vasmatkar@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
>>
Re: REST implementation
Posted by Al Byers <by...@gmail.com>.
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.vasmatkar@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
>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
Not a big deal, saw that when applying as a patch:
git apply 35.patch
35.patch:364: trailing whitespace.
* GET /rest/services/{serviceName}?inParams=<URLEncodedJSON>
35.patch:765: trailing whitespace.
xmlns:xl="http://www.w3.org/1999/xlink"
35.patch:2813: trailing whitespace.
35.patch:486: new blank line at EOF.
+
35.patch:772: new blank line at EOF.
+
warning: 5 lines add whitespace errors.
Jacques
Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :
> Hi Girish,
>
> I'm just starting to review so I may miss things. Just a question for now. We have an option at
>
> https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv
>
> to (Show wsdl <https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv&show_wsdl=true>)
>
> Would it be possible to have the same for REST?
>
> Thanks
>
> Jacques
>
> Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :
>> Greetings!
>>
>> I have created a PR to add a REST component -
>> https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
>> and let me know what you think and let me know if you face any issues. I
>> intend to merge it in a week from now.
>>
>> With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
>> "action" attribute to the service definition now merged, this above
>> component should be able to expose exportable (export=true) and
>> actionable(action=GET|POST) services via REST.
>>
>> Once the changes for nested attributes (OFBIZ-11902
>> <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
>> be making corresponding changes in the GraphQL plugin to account for nested
>> attributes. OFBIZ-11902
>> <https://issues.apache.org/jira/browse/OFBIZ-11902> will
>> help in defining complex GraphQL mutations.
>>
>> I am parallelly also working on designing an XML DSL for REST that should
>> allow tying up REST resources with OFBiz services.
>>
>> Best,
>> Girish
>>
>>
>>
>> On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>
>>> Hi Girish,
>>>
>>> Yes, you got it.
>>>
>>> Web browser will popup a login dialog when response code is 401:
>>> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
>>> required\"");
>>>
>>> The popup is skipped and then react/vue/angular can handle the response:
>>> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
>>> required\"");
>>>
>>>
>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>> 发送时间: 2020年7月9日 14:54
>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>> 主题: Re: REST implementation
>>>
>>> Hi Shi
>>>
>>> Thanks for taking a look at it. I have a question on "WWW-Authenticate"
>>> header so please clarify and I can make appropriate changes accordingly -
>>>
>>> All I am finding is that to prevent the pop-up, either return 403 (which I
>>> do not want to do) or not include "WWW-Authenticate" header at all (not
>>> inclined to do this as well because then we would be violating the spec).
>>> Do you mean to NOT start the value of the header with "Bearer" ?
>>> so instead of below
>>>
>>> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
>>>
>>> should we change it to
>>>
>>> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
>>>
>>> I did not test it, but I can just change it like this without testing if
>>> you can please confirm it will prevent the browser dialog.
>>>
>>> Thanks again for the review.
>>>
>>> Best,
>>> Girish
>>>
>>> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>>
>>>> Hi Girish,
>>>>
>>>> Excellent.
>>>>
>>>> Only one suggestion from my quick view, when response code is 401, the
>>>> "WWW-Authenticate" header should be set to start with a word NOT “Bearer
>>>> …”, this can prevent web browser from popping up a login dialog.
>>>>
>>>> Kind Regards,
>>>>
>>>> Shi Jinghai
>>>>
>>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>>> 发送时间: 2020年7月8日 20:47
>>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>>> 主题: Re: REST implementation
>>>>
>>>> Hi Folks
>>>>
>>>> I have added support for OpenApi Integration. The updated code can be
>>> found
>>>> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
>>>> through the changes and test at your end and let me know your thoughts.
>>>>
>>>> I am planning to do some refactoring and then raise initial PR for the
>>>> plug-in if the changes look good to everyone.
>>>>
>>>> Best,
>>>> Girish
>>>>
>>>>
>>>> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
>>>> carsten@dcs-verkaufssysteme.de> wrote:
>>>>
>>>>> Hi Girish,
>>>>>
>>>>> Thanks to clarify :)
>>>>> What caught me on the OpenAPI integration is the snippet quoted below
>>> and
>>>>> I realize I should have read it in context. Actually then it is aligned
>>>>> with my view.
>>>>>
>>>>> Warm regards
>>>>>
>>>>> Carsten
>>>>>
>>>>>>>>>> Initial implementation does not contain OpenApi integration yet.
>>>> And
>>>>>
>>>>
>>>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Jacques
Thanks for taking a look at this. Since, REST does not define any WSDL,
rather WADL, we can try to show it, however, since it is a component as a
starting point, it would probably be good if we can show WADL, if and when
it gets included in the framework. Because request coming to webtools
(show_wadl=true) will eventually be handled by the REST component to fetch
WADL. Also, as you figured out, Swagger is there too to describe the
service details.
Also, I will make the changes as you suggested in the OpenAPI
configuration. On 404, yes, that's normal because there is no resource at
the ROOT at the moment. This can however be a good addition if this URL can
return all resource definitions. I will make note of it and try to
implement it.
Best Regards,
Girish
On Sun, Aug 2, 2020 at 2:47 PM Jacques Le Roux <ja...@les7arts.com>
wrote:
> At https://localhost:8443/rest/ I get a 404 and in log
>
> javax.ws.rs.NotFoundException: HTTP 404 Not Found
> at
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:250)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
> at
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
> at
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
> at
> org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
> at
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
> at
> org.glassfish.jersey.servlet.ServletContainer.serviceImpl(ServletContainer.java:386)
> at
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:561)
> at
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:502)
> at
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:439)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> at org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
> at org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
> Normal?
>
> Le 02/08/2020 à 11:14, Jacques Le Roux a écrit :
> > I get that we have this information at
> >
> > https://localhost:8443/docs/swagger-ui.html
> >
> > like with
> >
> >
> https://localhost:8443/docs/swagger-ui.html#/Exported%20Services/findProductById
> >
> > So I guess we can put a link to that, rigth?
> >
> > Also there is no ofbiz@apache.org (at
> OpenApiResource::buildOpenApiContact) I'd suggest dev@ofbiz.apache.org
> >
> > For "Terms of service" I suggest a link to ASL2 and to remove the below
> direct link to it.
> >
> > BTW thanks Girish, this is really a great step forward :)
> >
> > Jacques
> >
> >
> > Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :
> >> Hi Girish,
> >>
> >> I'm just starting to review so I may miss things. Just a question for
> now. We have an option at
> >>
> >>
> https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv
> >>
> >> to (Show wsdl <
> https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv&show_wsdl=true
> >)
> >>
> >> Would it be possible to have the same for REST?
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >> Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :
> >>> Greetings!
> >>>
> >>> I have created a PR to add a REST component -
> >>> https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> >>> and let me know what you think and let me know if you face any issues.
> I
> >>> intend to merge it in a week from now.
> >>>
> >>> With the PR (https://github.com/apache/ofbiz-framework/pull/214) to
> add
> >>> "action" attribute to the service definition now merged, this above
> >>> component should be able to expose exportable (export=true) and
> >>> actionable(action=GET|POST) services via REST.
> >>>
> >>> Once the changes for nested attributes (OFBIZ-11902
> >>> <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will
> also
> >>> be making corresponding changes in the GraphQL plugin to account for
> nested
> >>> attributes. OFBIZ-11902
> >>> <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> >>> help in defining complex GraphQL mutations.
> >>>
> >>> I am parallelly also working on designing an XML DSL for REST that
> should
> >>> allow tying up REST resources with OFBiz services.
> >>>
> >>> Best,
> >>> Girish
> >>>
> >>>
> >>>
> >>> On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com>
> wrote:
> >>>
> >>>> Hi Girish,
> >>>>
> >>>> Yes, you got it.
> >>>>
> >>>> Web browser will popup a login dialog when response code is 401:
> >>>> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> >>>> required\"");
> >>>>
> >>>> The popup is skipped and then react/vue/angular can handle the
> response:
> >>>> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> >>>> required\"");
> >>>>
> >>>>
> >>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> >>>> 发送时间: 2020年7月9日 14:54
> >>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> >>>> 主题: Re: REST implementation
> >>>>
> >>>> Hi Shi
> >>>>
> >>>> Thanks for taking a look at it. I have a question on
> "WWW-Authenticate"
> >>>> header so please clarify and I can make appropriate changes
> accordingly -
> >>>>
> >>>> All I am finding is that to prevent the pop-up, either return 403
> (which I
> >>>> do not want to do) or not include "WWW-Authenticate" header at all
> (not
> >>>> inclined to do this as well because then we would be violating the
> spec).
> >>>> Do you mean to NOT start the value of the header with "Bearer" ?
> >>>> so instead of below
> >>>>
> >>>> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
> >>>>
> >>>> should we change it to
> >>>>
> >>>> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
> >>>>
> >>>> I did not test it, but I can just change it like this without testing
> if
> >>>> you can please confirm it will prevent the browser dialog.
> >>>>
> >>>> Thanks again for the review.
> >>>>
> >>>> Best,
> >>>> Girish
> >>>>
> >>>> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com>
> wrote:
> >>>>
> >>>>> Hi Girish,
> >>>>>
> >>>>> Excellent.
> >>>>>
> >>>>> Only one suggestion from my quick view, when response code is 401,
> the
> >>>>> "WWW-Authenticate" header should be set to start with a word NOT
> “Bearer
> >>>>> …”, this can prevent web browser from popping up a login dialog.
> >>>>>
> >>>>> Kind Regards,
> >>>>>
> >>>>> Shi Jinghai
> >>>>>
> >>>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> >>>>> 发送时间: 2020年7月8日 20:47
> >>>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> >>>>> 主题: Re: REST implementation
> >>>>>
> >>>>> Hi Folks
> >>>>>
> >>>>> I have added support for OpenApi Integration. The updated code can be
> >>>> found
> >>>>> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> >>>>> through the changes and test at your end and let me know your
> thoughts.
> >>>>>
> >>>>> I am planning to do some refactoring and then raise initial PR for
> the
> >>>>> plug-in if the changes look good to everyone.
> >>>>>
> >>>>> Best,
> >>>>> Girish
> >>>>>
> >>>>>
> >>>>> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> >>>>> carsten@dcs-verkaufssysteme.de> wrote:
> >>>>>
> >>>>>> Hi Girish,
> >>>>>>
> >>>>>> Thanks to clarify :)
> >>>>>> What caught me on the OpenAPI integration is the snippet quoted
> below
> >>>> and
> >>>>>> I realize I should have read it in context. Actually then it is
> aligned
> >>>>>> with my view.
> >>>>>>
> >>>>>> Warm regards
> >>>>>>
> >>>>>> Carsten
> >>>>>>
> >>>>>>>>>>> Initial implementation does not contain OpenApi integration
> yet.
> >>>>> And
> >>>>>>
> >>>>>
> >>>>
>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
At https://localhost:8443/rest/ I get a 404 and in log
javax.ws.rs.NotFoundException: HTTP 404 Not Found
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:250)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
at org.glassfish.jersey.servlet.ServletContainer.serviceImpl(ServletContainer.java:386)
at org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:561)
at org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:502)
at org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:439)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Normal?
Le 02/08/2020 à 11:14, Jacques Le Roux a écrit :
> I get that we have this information at
>
> https://localhost:8443/docs/swagger-ui.html
>
> like with
>
> https://localhost:8443/docs/swagger-ui.html#/Exported%20Services/findProductById
>
> So I guess we can put a link to that, rigth?
>
> Also there is no ofbiz@apache.org (at OpenApiResource::buildOpenApiContact) I'd suggest dev@ofbiz.apache.org
>
> For "Terms of service" I suggest a link to ASL2 and to remove the below direct link to it.
>
> BTW thanks Girish, this is really a great step forward :)
>
> Jacques
>
>
> Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :
>> Hi Girish,
>>
>> I'm just starting to review so I may miss things. Just a question for now. We have an option at
>>
>> https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv
>>
>> to (Show wsdl <https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv&show_wsdl=true>)
>>
>> Would it be possible to have the same for REST?
>>
>> Thanks
>>
>> Jacques
>>
>> Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :
>>> Greetings!
>>>
>>> I have created a PR to add a REST component -
>>> https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
>>> and let me know what you think and let me know if you face any issues. I
>>> intend to merge it in a week from now.
>>>
>>> With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
>>> "action" attribute to the service definition now merged, this above
>>> component should be able to expose exportable (export=true) and
>>> actionable(action=GET|POST) services via REST.
>>>
>>> Once the changes for nested attributes (OFBIZ-11902
>>> <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
>>> be making corresponding changes in the GraphQL plugin to account for nested
>>> attributes. OFBIZ-11902
>>> <https://issues.apache.org/jira/browse/OFBIZ-11902> will
>>> help in defining complex GraphQL mutations.
>>>
>>> I am parallelly also working on designing an XML DSL for REST that should
>>> allow tying up REST resources with OFBiz services.
>>>
>>> Best,
>>> Girish
>>>
>>>
>>>
>>> On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>>
>>>> Hi Girish,
>>>>
>>>> Yes, you got it.
>>>>
>>>> Web browser will popup a login dialog when response code is 401:
>>>> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
>>>> required\"");
>>>>
>>>> The popup is skipped and then react/vue/angular can handle the response:
>>>> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
>>>> required\"");
>>>>
>>>>
>>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>>> 发送时间: 2020年7月9日 14:54
>>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>>> 主题: Re: REST implementation
>>>>
>>>> Hi Shi
>>>>
>>>> Thanks for taking a look at it. I have a question on "WWW-Authenticate"
>>>> header so please clarify and I can make appropriate changes accordingly -
>>>>
>>>> All I am finding is that to prevent the pop-up, either return 403 (which I
>>>> do not want to do) or not include "WWW-Authenticate" header at all (not
>>>> inclined to do this as well because then we would be violating the spec).
>>>> Do you mean to NOT start the value of the header with "Bearer" ?
>>>> so instead of below
>>>>
>>>> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
>>>>
>>>> should we change it to
>>>>
>>>> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
>>>>
>>>> I did not test it, but I can just change it like this without testing if
>>>> you can please confirm it will prevent the browser dialog.
>>>>
>>>> Thanks again for the review.
>>>>
>>>> Best,
>>>> Girish
>>>>
>>>> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>>>
>>>>> Hi Girish,
>>>>>
>>>>> Excellent.
>>>>>
>>>>> Only one suggestion from my quick view, when response code is 401, the
>>>>> "WWW-Authenticate" header should be set to start with a word NOT “Bearer
>>>>> …”, this can prevent web browser from popping up a login dialog.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Shi Jinghai
>>>>>
>>>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>>>> 发送时间: 2020年7月8日 20:47
>>>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>>>> 主题: Re: REST implementation
>>>>>
>>>>> Hi Folks
>>>>>
>>>>> I have added support for OpenApi Integration. The updated code can be
>>>> found
>>>>> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
>>>>> through the changes and test at your end and let me know your thoughts.
>>>>>
>>>>> I am planning to do some refactoring and then raise initial PR for the
>>>>> plug-in if the changes look good to everyone.
>>>>>
>>>>> Best,
>>>>> Girish
>>>>>
>>>>>
>>>>> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
>>>>> carsten@dcs-verkaufssysteme.de> wrote:
>>>>>
>>>>>> Hi Girish,
>>>>>>
>>>>>> Thanks to clarify :)
>>>>>> What caught me on the OpenAPI integration is the snippet quoted below
>>>> and
>>>>>> I realize I should have read it in context. Actually then it is aligned
>>>>>> with my view.
>>>>>>
>>>>>> Warm regards
>>>>>>
>>>>>> Carsten
>>>>>>
>>>>>>>>>>> Initial implementation does not contain OpenApi integration yet.
>>>>> And
>>>>>>
>>>>>
>>>>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
I get that we have this information at
https://localhost:8443/docs/swagger-ui.html
like with
https://localhost:8443/docs/swagger-ui.html#/Exported%20Services/findProductById
So I guess we can put a link to that, rigth?
Also there is no ofbiz@apache.org (at OpenApiResource::buildOpenApiContact) I'd suggest dev@ofbiz.apache.org
For "Terms of service" I suggest a link to ASL2 and to remove the below direct link to it.
BTW thanks Girish, this is really a great step forward :)
Jacques
Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :
> Hi Girish,
>
> I'm just starting to review so I may miss things. Just a question for now. We have an option at
>
> https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv
>
> to (Show wsdl <https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv&show_wsdl=true>)
>
> Would it be possible to have the same for REST?
>
> Thanks
>
> Jacques
>
> Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :
>> Greetings!
>>
>> I have created a PR to add a REST component -
>> https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
>> and let me know what you think and let me know if you face any issues. I
>> intend to merge it in a week from now.
>>
>> With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
>> "action" attribute to the service definition now merged, this above
>> component should be able to expose exportable (export=true) and
>> actionable(action=GET|POST) services via REST.
>>
>> Once the changes for nested attributes (OFBIZ-11902
>> <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
>> be making corresponding changes in the GraphQL plugin to account for nested
>> attributes. OFBIZ-11902
>> <https://issues.apache.org/jira/browse/OFBIZ-11902> will
>> help in defining complex GraphQL mutations.
>>
>> I am parallelly also working on designing an XML DSL for REST that should
>> allow tying up REST resources with OFBiz services.
>>
>> Best,
>> Girish
>>
>>
>>
>> On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>
>>> Hi Girish,
>>>
>>> Yes, you got it.
>>>
>>> Web browser will popup a login dialog when response code is 401:
>>> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
>>> required\"");
>>>
>>> The popup is skipped and then react/vue/angular can handle the response:
>>> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
>>> required\"");
>>>
>>>
>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>> 发送时间: 2020年7月9日 14:54
>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>> 主题: Re: REST implementation
>>>
>>> Hi Shi
>>>
>>> Thanks for taking a look at it. I have a question on "WWW-Authenticate"
>>> header so please clarify and I can make appropriate changes accordingly -
>>>
>>> All I am finding is that to prevent the pop-up, either return 403 (which I
>>> do not want to do) or not include "WWW-Authenticate" header at all (not
>>> inclined to do this as well because then we would be violating the spec).
>>> Do you mean to NOT start the value of the header with "Bearer" ?
>>> so instead of below
>>>
>>> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
>>>
>>> should we change it to
>>>
>>> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
>>>
>>> I did not test it, but I can just change it like this without testing if
>>> you can please confirm it will prevent the browser dialog.
>>>
>>> Thanks again for the review.
>>>
>>> Best,
>>> Girish
>>>
>>> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>>
>>>> Hi Girish,
>>>>
>>>> Excellent.
>>>>
>>>> Only one suggestion from my quick view, when response code is 401, the
>>>> "WWW-Authenticate" header should be set to start with a word NOT “Bearer
>>>> …”, this can prevent web browser from popping up a login dialog.
>>>>
>>>> Kind Regards,
>>>>
>>>> Shi Jinghai
>>>>
>>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>>> 发送时间: 2020年7月8日 20:47
>>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>>> 主题: Re: REST implementation
>>>>
>>>> Hi Folks
>>>>
>>>> I have added support for OpenApi Integration. The updated code can be
>>> found
>>>> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
>>>> through the changes and test at your end and let me know your thoughts.
>>>>
>>>> I am planning to do some refactoring and then raise initial PR for the
>>>> plug-in if the changes look good to everyone.
>>>>
>>>> Best,
>>>> Girish
>>>>
>>>>
>>>> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
>>>> carsten@dcs-verkaufssysteme.de> wrote:
>>>>
>>>>> Hi Girish,
>>>>>
>>>>> Thanks to clarify :)
>>>>> What caught me on the OpenAPI integration is the snippet quoted below
>>> and
>>>>> I realize I should have read it in context. Actually then it is aligned
>>>>> with my view.
>>>>>
>>>>> Warm regards
>>>>>
>>>>> Carsten
>>>>>
>>>>>>>>>> Initial implementation does not contain OpenApi integration yet.
>>>> And
>>>>>
>>>>
>>>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Girish,
I'm just starting to review so I may miss things. Just a question for now. We have an option at
https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv
to (Show wsdl <https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv&show_wsdl=true>)
Would it be possible to have the same for REST?
Thanks
Jacques
Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :
> Greetings!
>
> I have created a PR to add a REST component -
> https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> and let me know what you think and let me know if you face any issues. I
> intend to merge it in a week from now.
>
> With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
> "action" attribute to the service definition now merged, this above
> component should be able to expose exportable (export=true) and
> actionable(action=GET|POST) services via REST.
>
> Once the changes for nested attributes (OFBIZ-11902
> <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
> be making corresponding changes in the GraphQL plugin to account for nested
> attributes. OFBIZ-11902
> <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> help in defining complex GraphQL mutations.
>
> I am parallelly also working on designing an XML DSL for REST that should
> allow tying up REST resources with OFBiz services.
>
> Best,
> Girish
>
>
>
> On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
>
>> Hi Girish,
>>
>> Yes, you got it.
>>
>> Web browser will popup a login dialog when response code is 401:
>> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
>> required\"");
>>
>> The popup is skipped and then react/vue/angular can handle the response:
>> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
>> required\"");
>>
>>
>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>> 发送时间: 2020年7月9日 14:54
>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>> 主题: Re: REST implementation
>>
>> Hi Shi
>>
>> Thanks for taking a look at it. I have a question on "WWW-Authenticate"
>> header so please clarify and I can make appropriate changes accordingly -
>>
>> All I am finding is that to prevent the pop-up, either return 403 (which I
>> do not want to do) or not include "WWW-Authenticate" header at all (not
>> inclined to do this as well because then we would be violating the spec).
>> Do you mean to NOT start the value of the header with "Bearer" ?
>> so instead of below
>>
>> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
>>
>> should we change it to
>>
>> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
>>
>> I did not test it, but I can just change it like this without testing if
>> you can please confirm it will prevent the browser dialog.
>>
>> Thanks again for the review.
>>
>> Best,
>> Girish
>>
>> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
>>
>>> Hi Girish,
>>>
>>> Excellent.
>>>
>>> Only one suggestion from my quick view, when response code is 401, the
>>> "WWW-Authenticate" header should be set to start with a word NOT “Bearer
>>> …”, this can prevent web browser from popping up a login dialog.
>>>
>>> Kind Regards,
>>>
>>> Shi Jinghai
>>>
>>> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
>>> 发送时间: 2020年7月8日 20:47
>>> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
>>> 主题: Re: REST implementation
>>>
>>> Hi Folks
>>>
>>> I have added support for OpenApi Integration. The updated code can be
>> found
>>> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
>>> through the changes and test at your end and let me know your thoughts.
>>>
>>> I am planning to do some refactoring and then raise initial PR for the
>>> plug-in if the changes look good to everyone.
>>>
>>> Best,
>>> Girish
>>>
>>>
>>> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
>>> carsten@dcs-verkaufssysteme.de> wrote:
>>>
>>>> Hi Girish,
>>>>
>>>> Thanks to clarify :)
>>>> What caught me on the OpenAPI integration is the snippet quoted below
>> and
>>>> I realize I should have read it in context. Actually then it is aligned
>>>> with my view.
>>>>
>>>> Warm regards
>>>>
>>>> Carsten
>>>>
>>>>>>>>> Initial implementation does not contain OpenApi integration yet.
>>> And
>>>>
>>>
>>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Shi and Dan
Thanks for the OAuth2 implementation and Dan, thanks for your evaluation. I
have now included an endpoint for clients to authenticate themselves before
start using the API. Also, since the endpoint is included in OpenAPI, the
same can be executed directly from Swagger UI.
curl -X POST "https://localhost:8443/rest/auth/token" -H "accept:
application/json" -H "Authorization: Basic YWRtaW46b2ZiaXo="
This gets you the generated token with expiry as set in security.properties
file.
{
"statusCode": 200,
"statusDescription": "OK",
"successMessage": "Token granted.",
"data": {
"access_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJ1c2VyTG9naW5JZCI6ImFkbWluIiwiaXNzIjoiQXBhY2hlT0ZCaXoiLCJleHAiOjE1OTY3MDk4MjAsImlhdCI6MTU5NjcwODAyMH0.9Hj4pkkeQowAMxPLrI_To0WTohxxgVR6FoViyx5HoboTACQZ4iqDyqiIBodkuCVsZwOTPT1RSAQJ0L_oSVMqBA",
"token_type": "Bearer",
"expires_in": "1800"
}
}
The generated token can then be used to make API calls using Bearer Auth
Scheme. I have updated README here :
https://github.com/girishvasmatkar/ofbiz-plugins/blob/trunk/ofbiz-rest-impl/README.adoc
Best,
Girish
On Wed, Aug 5, 2020 at 8:13 PM Daniel Watford <da...@foomoo.co.uk> wrote:
> Hi Girish,
>
> I've been able to authenticate with the REST api using the token you
> mentioned.
>
> I find the REST service very interesting as I think it has the potential to
> drastically simplify some of the lookup-style functionality currently
> implemented.
>
> As an extension to your PR I tried out a couple of things that might be
> useful while you continue to explore REST service opportunities.
>
> Please see this branch:
>
> https://github.com/danwatford/ofbiz-framework/commits/rest-experiements-based-on-pr214
>
>
> There are two commits on top of PR214.
>
> The first commit uses REST to look up State/Province values for a given
> country. This functionality is used when editing postal addresses. In this
> commit I've modified the editcontactmech form to use a REST endpoint to
> retrieve state/province information. If you have demo data loaded locally
> you can see the result here:
>
> https://localhost:8443/partymgr/control/editcontactmech?partyId=Company&contactMechId=10000
>
> There wasn't too much of a saving here as the controller servlet is already
> configured to return JSON in response to these lookups, but making use of
> REST would sidestep the need to create controller.xml entries.
>
>
> The second commit uses REST to look up User Logins for the autocomplete
> field displayed here: https://localhost:8443/partymgr/control/main
>
> As you type into the User Login ID field REST calls are made to endpoint
> https://localhost:8443/rest/services/lookupUserLogin to search for
> matching
> user logins.
>
> The potential savings for this style of lookup are a reduction in
> complexity on the client and server side.
>
> At the moment AJAX lookup requests are processed as regular screen
> renderings, but with a decorator-loaded screen detecting that the
> ajaxLookup parameter is set and then triggering
> common/groovyScripts/FindAutocompleteOptions.groovy to run to perform the
> search. The search results are then encoded as a piece of javascript inside
> an HTML response.
> The client loads that HTML response into an automatically generated div,
> causing the javascript to execute and populate a global variable.
> The client then reads that global variable to generate the options to be
> displayed by the autocomplete widget.
>
> It is quite a convoluted chain of code to follow, but I imagine it was
> necessary at the time to make lookups work with the screen view rendering
> approach. Calling REST services instead will remove the need to generate
> javascript scripts embedded in HTML responses.
>
> Please note, the code written is very hacky at the moment and hardcoded to
> have ofbiz accessible at https://localhost:8443/. Notifying the client
> code
> of REST endpoints has been done by 'inappropriately reusing' other
> configuration items.
>
> Looking forward to seeing what comes next. Perhaps we could create a new
> ModelForm.RestLookupField to work similarly to ModelForm.LookupField, but
> making use of REST calls instead.
>
> Thanks,
>
> Dan.
>
>
> On Sun, 2 Aug 2020 at 11:03, Girish Vasmatkar <
> girish.vasmatkar@hotwaxsystems.com> wrote:
>
> > Hi Daniel
> >
> > You can use the JWT token in the README of. Sorry, if it is not clearly
> > documented, this will be improved upon further as I make more changes.
> >
> https://github.com/girishvasmatkar/ofbiz-plugins/tree/trunk/ofbiz-rest-impl
> >
> > I need to implement an API endpoint that eventually generates a JWT token
> > that can be issued to the client to make subsequent API calls. Until
> then,
> > please use the once mentioned in the README examples. That JWT has userId
> > claim value as admin assuming admin would have got himself authenticated
> > and a JWT was issued to him.
> >
> > I will soon add an API endpoint to issue JWTs and will update README
> > accordingly. I hope that answers your question.
> >
> > Best Regards,
> > Girish
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Aug 2, 2020 at 3:21 PM Daniel Watford <da...@foomoo.co.uk> wrote:
> >
> > > Hi Girish,
> > >
> > > I wanted to try out some REST calls using Swagger-ui (
> > > https://localhost:8443/docs/swagger-ui.html) but don't know how to
> > > authenticate to get a JWT.
> > >
> > > Apologies if I missed the instructions elsewhere but please could you
> > > advise on how to authenticate against the REST api?
> > >
> > > Thanks,
> > >
> > > Dan.
> > >
> > > On Fri, 31 Jul 2020 at 09:34, Girish Vasmatkar <
> > > girish.vasmatkar@hotwaxsystems.com> wrote:
> > >
> > > > Greetings!
> > > >
> > > > I have created a PR to add a REST component -
> > > > https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> > > > and let me know what you think and let me know if you face any
> issues.
> > I
> > > > intend to merge it in a week from now.
> > > >
> > > > With the PR (https://github.com/apache/ofbiz-framework/pull/214) to
> > add
> > > > "action" attribute to the service definition now merged, this above
> > > > component should be able to expose exportable (export=true) and
> > > > actionable(action=GET|POST) services via REST.
> > > >
> > > > Once the changes for nested attributes (OFBIZ-11902
> > > > <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I
> will
> > > also
> > > > be making corresponding changes in the GraphQL plugin to account for
> > > nested
> > > > attributes. OFBIZ-11902
> > > > <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> > > > help in defining complex GraphQL mutations.
> > > >
> > > > I am parallelly also working on designing an XML DSL for REST that
> > should
> > > > allow tying up REST resources with OFBiz services.
> > > >
> > > > Best,
> > > > Girish
> > > >
> > > >
> > > >
> > > > On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com>
> > wrote:
> > > >
> > > > > Hi Girish,
> > > > >
> > > > > Yes, you got it.
> > > > >
> > > > > Web browser will popup a login dialog when response code is 401:
> > > > > setResponseHeader("WWW-Authenticate", "Bearer
> realm=\"authentication
> > > > > required\"");
> > > > >
> > > > > The popup is skipped and then react/vue/angular can handle the
> > > response:
> > > > > setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> > > > > required\"");
> > > > >
> > > > >
> > > > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > > > 发送时间: 2020年7月9日 14:54
> > > > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > > > 主题: Re: REST implementation
> > > > >
> > > > > Hi Shi
> > > > >
> > > > > Thanks for taking a look at it. I have a question on
> > "WWW-Authenticate"
> > > > > header so please clarify and I can make appropriate changes
> > > accordingly -
> > > > >
> > > > > All I am finding is that to prevent the pop-up, either return 403
> > > (which
> > > > I
> > > > > do not want to do) or not include "WWW-Authenticate" header at all
> > (not
> > > > > inclined to do this as well because then we would be violating the
> > > spec).
> > > > > Do you mean to NOT start the value of the header with "Bearer" ?
> > > > > so instead of below
> > > > >
> > > > > *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
> > > > >
> > > > > should we change it to
> > > > >
> > > > > *WWW-Authenticate: xBearer realm="Access to OFBiz",
> charset="UTF-8"*
> > > > >
> > > > > I did not test it, but I can just change it like this without
> testing
> > > if
> > > > > you can please confirm it will prevent the browser dialog.
> > > > >
> > > > > Thanks again for the review.
> > > > >
> > > > > Best,
> > > > > Girish
> > > > >
> > > > > On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com>
> > > wrote:
> > > > >
> > > > > > Hi Girish,
> > > > > >
> > > > > > Excellent.
> > > > > >
> > > > > > Only one suggestion from my quick view, when response code is
> 401,
> > > the
> > > > > > "WWW-Authenticate" header should be set to start with a word NOT
> > > > “Bearer
> > > > > > …”, this can prevent web browser from popping up a login dialog.
> > > > > >
> > > > > > Kind Regards,
> > > > > >
> > > > > > Shi Jinghai
> > > > > >
> > > > > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > > > > 发送时间: 2020年7月8日 20:47
> > > > > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > > > > 主题: Re: REST implementation
> > > > > >
> > > > > > Hi Folks
> > > > > >
> > > > > > I have added support for OpenApi Integration. The updated code
> can
> > be
> > > > > found
> > > > > > here : https://github.com/girishvasmatkar/ofbiz-rest-impl.
> Please
> > go
> > > > > > through the changes and test at your end and let me know your
> > > thoughts.
> > > > > >
> > > > > > I am planning to do some refactoring and then raise initial PR
> for
> > > the
> > > > > > plug-in if the changes look good to everyone.
> > > > > >
> > > > > > Best,
> > > > > > Girish
> > > > > >
> > > > > >
> > > > > > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > > > > > carsten@dcs-verkaufssysteme.de> wrote:
> > > > > >
> > > > > > > Hi Girish,
> > > > > > >
> > > > > > > Thanks to clarify :)
> > > > > > > What caught me on the OpenAPI integration is the snippet quoted
> > > below
> > > > > and
> > > > > > > I realize I should have read it in context. Actually then it is
> > > > aligned
> > > > > > > with my view.
> > > > > > >
> > > > > > > Warm regards
> > > > > > >
> > > > > > > Carsten
> > > > > > >
> > > > > > > >>>>> Initial implementation does not contain OpenApi
> integration
> > > > yet.
> > > > > > And
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Daniel Watford
> > >
> >
>
>
> --
> Daniel Watford
>
Re: REST implementation
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hi Girish,
I've been able to authenticate with the REST api using the token you
mentioned.
I find the REST service very interesting as I think it has the potential to
drastically simplify some of the lookup-style functionality currently
implemented.
As an extension to your PR I tried out a couple of things that might be
useful while you continue to explore REST service opportunities.
Please see this branch:
https://github.com/danwatford/ofbiz-framework/commits/rest-experiements-based-on-pr214
There are two commits on top of PR214.
The first commit uses REST to look up State/Province values for a given
country. This functionality is used when editing postal addresses. In this
commit I've modified the editcontactmech form to use a REST endpoint to
retrieve state/province information. If you have demo data loaded locally
you can see the result here:
https://localhost:8443/partymgr/control/editcontactmech?partyId=Company&contactMechId=10000
There wasn't too much of a saving here as the controller servlet is already
configured to return JSON in response to these lookups, but making use of
REST would sidestep the need to create controller.xml entries.
The second commit uses REST to look up User Logins for the autocomplete
field displayed here: https://localhost:8443/partymgr/control/main
As you type into the User Login ID field REST calls are made to endpoint
https://localhost:8443/rest/services/lookupUserLogin to search for matching
user logins.
The potential savings for this style of lookup are a reduction in
complexity on the client and server side.
At the moment AJAX lookup requests are processed as regular screen
renderings, but with a decorator-loaded screen detecting that the
ajaxLookup parameter is set and then triggering
common/groovyScripts/FindAutocompleteOptions.groovy to run to perform the
search. The search results are then encoded as a piece of javascript inside
an HTML response.
The client loads that HTML response into an automatically generated div,
causing the javascript to execute and populate a global variable.
The client then reads that global variable to generate the options to be
displayed by the autocomplete widget.
It is quite a convoluted chain of code to follow, but I imagine it was
necessary at the time to make lookups work with the screen view rendering
approach. Calling REST services instead will remove the need to generate
javascript scripts embedded in HTML responses.
Please note, the code written is very hacky at the moment and hardcoded to
have ofbiz accessible at https://localhost:8443/. Notifying the client code
of REST endpoints has been done by 'inappropriately reusing' other
configuration items.
Looking forward to seeing what comes next. Perhaps we could create a new
ModelForm.RestLookupField to work similarly to ModelForm.LookupField, but
making use of REST calls instead.
Thanks,
Dan.
On Sun, 2 Aug 2020 at 11:03, Girish Vasmatkar <
girish.vasmatkar@hotwaxsystems.com> wrote:
> Hi Daniel
>
> You can use the JWT token in the README of. Sorry, if it is not clearly
> documented, this will be improved upon further as I make more changes.
> https://github.com/girishvasmatkar/ofbiz-plugins/tree/trunk/ofbiz-rest-impl
>
> I need to implement an API endpoint that eventually generates a JWT token
> that can be issued to the client to make subsequent API calls. Until then,
> please use the once mentioned in the README examples. That JWT has userId
> claim value as admin assuming admin would have got himself authenticated
> and a JWT was issued to him.
>
> I will soon add an API endpoint to issue JWTs and will update README
> accordingly. I hope that answers your question.
>
> Best Regards,
> Girish
>
>
>
>
>
>
>
> On Sun, Aug 2, 2020 at 3:21 PM Daniel Watford <da...@foomoo.co.uk> wrote:
>
> > Hi Girish,
> >
> > I wanted to try out some REST calls using Swagger-ui (
> > https://localhost:8443/docs/swagger-ui.html) but don't know how to
> > authenticate to get a JWT.
> >
> > Apologies if I missed the instructions elsewhere but please could you
> > advise on how to authenticate against the REST api?
> >
> > Thanks,
> >
> > Dan.
> >
> > On Fri, 31 Jul 2020 at 09:34, Girish Vasmatkar <
> > girish.vasmatkar@hotwaxsystems.com> wrote:
> >
> > > Greetings!
> > >
> > > I have created a PR to add a REST component -
> > > https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> > > and let me know what you think and let me know if you face any issues.
> I
> > > intend to merge it in a week from now.
> > >
> > > With the PR (https://github.com/apache/ofbiz-framework/pull/214) to
> add
> > > "action" attribute to the service definition now merged, this above
> > > component should be able to expose exportable (export=true) and
> > > actionable(action=GET|POST) services via REST.
> > >
> > > Once the changes for nested attributes (OFBIZ-11902
> > > <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will
> > also
> > > be making corresponding changes in the GraphQL plugin to account for
> > nested
> > > attributes. OFBIZ-11902
> > > <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> > > help in defining complex GraphQL mutations.
> > >
> > > I am parallelly also working on designing an XML DSL for REST that
> should
> > > allow tying up REST resources with OFBiz services.
> > >
> > > Best,
> > > Girish
> > >
> > >
> > >
> > > On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com>
> wrote:
> > >
> > > > Hi Girish,
> > > >
> > > > Yes, you got it.
> > > >
> > > > Web browser will popup a login dialog when response code is 401:
> > > > setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> > > > required\"");
> > > >
> > > > The popup is skipped and then react/vue/angular can handle the
> > response:
> > > > setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> > > > required\"");
> > > >
> > > >
> > > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > > 发送时间: 2020年7月9日 14:54
> > > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > > 主题: Re: REST implementation
> > > >
> > > > Hi Shi
> > > >
> > > > Thanks for taking a look at it. I have a question on
> "WWW-Authenticate"
> > > > header so please clarify and I can make appropriate changes
> > accordingly -
> > > >
> > > > All I am finding is that to prevent the pop-up, either return 403
> > (which
> > > I
> > > > do not want to do) or not include "WWW-Authenticate" header at all
> (not
> > > > inclined to do this as well because then we would be violating the
> > spec).
> > > > Do you mean to NOT start the value of the header with "Bearer" ?
> > > > so instead of below
> > > >
> > > > *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
> > > >
> > > > should we change it to
> > > >
> > > > *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
> > > >
> > > > I did not test it, but I can just change it like this without testing
> > if
> > > > you can please confirm it will prevent the browser dialog.
> > > >
> > > > Thanks again for the review.
> > > >
> > > > Best,
> > > > Girish
> > > >
> > > > On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com>
> > wrote:
> > > >
> > > > > Hi Girish,
> > > > >
> > > > > Excellent.
> > > > >
> > > > > Only one suggestion from my quick view, when response code is 401,
> > the
> > > > > "WWW-Authenticate" header should be set to start with a word NOT
> > > “Bearer
> > > > > …”, this can prevent web browser from popping up a login dialog.
> > > > >
> > > > > Kind Regards,
> > > > >
> > > > > Shi Jinghai
> > > > >
> > > > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > > > 发送时间: 2020年7月8日 20:47
> > > > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > > > 主题: Re: REST implementation
> > > > >
> > > > > Hi Folks
> > > > >
> > > > > I have added support for OpenApi Integration. The updated code can
> be
> > > > found
> > > > > here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please
> go
> > > > > through the changes and test at your end and let me know your
> > thoughts.
> > > > >
> > > > > I am planning to do some refactoring and then raise initial PR for
> > the
> > > > > plug-in if the changes look good to everyone.
> > > > >
> > > > > Best,
> > > > > Girish
> > > > >
> > > > >
> > > > > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > > > > carsten@dcs-verkaufssysteme.de> wrote:
> > > > >
> > > > > > Hi Girish,
> > > > > >
> > > > > > Thanks to clarify :)
> > > > > > What caught me on the OpenAPI integration is the snippet quoted
> > below
> > > > and
> > > > > > I realize I should have read it in context. Actually then it is
> > > aligned
> > > > > > with my view.
> > > > > >
> > > > > > Warm regards
> > > > > >
> > > > > > Carsten
> > > > > >
> > > > > > >>>>> Initial implementation does not contain OpenApi integration
> > > yet.
> > > > > And
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Daniel Watford
> >
>
--
Daniel Watford
Re: REST implementation
Posted by Shi Jinghai <hu...@hotmail.com>.
Hi Daniel and Girish,
I updated my OFBiz-CAS plugin several days ago, it’s an OAuth2 implement, and there’s an openapi-demo in the plugin:
https://github.com/langhua/OFBiz-CAS/tree/ofbiz-17.12.03-cas-5.3.15.1
Hope it could be helpful to you.
Kind Regards,
Shi Jinghai
发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用
发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
发送时间: 2020年8月2日 18:03
收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
主题: Re: REST implementation
Hi Daniel
You can use the JWT token in the README of. Sorry, if it is not clearly
documented, this will be improved upon further as I make more changes.
https://github.com/girishvasmatkar/ofbiz-plugins/tree/trunk/ofbiz-rest-impl
I need to implement an API endpoint that eventually generates a JWT token
that can be issued to the client to make subsequent API calls. Until then,
please use the once mentioned in the README examples. That JWT has userId
claim value as admin assuming admin would have got himself authenticated
and a JWT was issued to him.
I will soon add an API endpoint to issue JWTs and will update README
accordingly. I hope that answers your question.
Best Regards,
Girish
On Sun, Aug 2, 2020 at 3:21 PM Daniel Watford <da...@foomoo.co.uk> wrote:
> Hi Girish,
>
> I wanted to try out some REST calls using Swagger-ui (
> https://localhost:8443/docs/swagger-ui.html) but don't know how to
> authenticate to get a JWT.
>
> Apologies if I missed the instructions elsewhere but please could you
> advise on how to authenticate against the REST api?
>
> Thanks,
>
> Dan.
>
> On Fri, 31 Jul 2020 at 09:34, Girish Vasmatkar <
> girish.vasmatkar@hotwaxsystems.com> wrote:
>
> > Greetings!
> >
> > I have created a PR to add a REST component -
> > https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> > and let me know what you think and let me know if you face any issues. I
> > intend to merge it in a week from now.
> >
> > With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
> > "action" attribute to the service definition now merged, this above
> > component should be able to expose exportable (export=true) and
> > actionable(action=GET|POST) services via REST.
> >
> > Once the changes for nested attributes (OFBIZ-11902
> > <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will
> also
> > be making corresponding changes in the GraphQL plugin to account for
> nested
> > attributes. OFBIZ-11902
> > <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> > help in defining complex GraphQL mutations.
> >
> > I am parallelly also working on designing an XML DSL for REST that should
> > allow tying up REST resources with OFBiz services.
> >
> > Best,
> > Girish
> >
> >
> >
> > On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
> >
> > > Hi Girish,
> > >
> > > Yes, you got it.
> > >
> > > Web browser will popup a login dialog when response code is 401:
> > > setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> > > required\"");
> > >
> > > The popup is skipped and then react/vue/angular can handle the
> response:
> > > setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> > > required\"");
> > >
> > >
> > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > 发送时间: 2020年7月9日 14:54
> > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > 主题: Re: REST implementation
> > >
> > > Hi Shi
> > >
> > > Thanks for taking a look at it. I have a question on "WWW-Authenticate"
> > > header so please clarify and I can make appropriate changes
> accordingly -
> > >
> > > All I am finding is that to prevent the pop-up, either return 403
> (which
> > I
> > > do not want to do) or not include "WWW-Authenticate" header at all (not
> > > inclined to do this as well because then we would be violating the
> spec).
> > > Do you mean to NOT start the value of the header with "Bearer" ?
> > > so instead of below
> > >
> > > *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
> > >
> > > should we change it to
> > >
> > > *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
> > >
> > > I did not test it, but I can just change it like this without testing
> if
> > > you can please confirm it will prevent the browser dialog.
> > >
> > > Thanks again for the review.
> > >
> > > Best,
> > > Girish
> > >
> > > On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com>
> wrote:
> > >
> > > > Hi Girish,
> > > >
> > > > Excellent.
> > > >
> > > > Only one suggestion from my quick view, when response code is 401,
> the
> > > > "WWW-Authenticate" header should be set to start with a word NOT
> > “Bearer
> > > > …”, this can prevent web browser from popping up a login dialog.
> > > >
> > > > Kind Regards,
> > > >
> > > > Shi Jinghai
> > > >
> > > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > > 发送时间: 2020年7月8日 20:47
> > > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > > 主题: Re: REST implementation
> > > >
> > > > Hi Folks
> > > >
> > > > I have added support for OpenApi Integration. The updated code can be
> > > found
> > > > here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> > > > through the changes and test at your end and let me know your
> thoughts.
> > > >
> > > > I am planning to do some refactoring and then raise initial PR for
> the
> > > > plug-in if the changes look good to everyone.
> > > >
> > > > Best,
> > > > Girish
> > > >
> > > >
> > > > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > > > carsten@dcs-verkaufssysteme.de> wrote:
> > > >
> > > > > Hi Girish,
> > > > >
> > > > > Thanks to clarify :)
> > > > > What caught me on the OpenAPI integration is the snippet quoted
> below
> > > and
> > > > > I realize I should have read it in context. Actually then it is
> > aligned
> > > > > with my view.
> > > > >
> > > > > Warm regards
> > > > >
> > > > > Carsten
> > > > >
> > > > > >>>>> Initial implementation does not contain OpenApi integration
> > yet.
> > > > And
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Watford
>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Daniel
You can use the JWT token in the README of. Sorry, if it is not clearly
documented, this will be improved upon further as I make more changes.
https://github.com/girishvasmatkar/ofbiz-plugins/tree/trunk/ofbiz-rest-impl
I need to implement an API endpoint that eventually generates a JWT token
that can be issued to the client to make subsequent API calls. Until then,
please use the once mentioned in the README examples. That JWT has userId
claim value as admin assuming admin would have got himself authenticated
and a JWT was issued to him.
I will soon add an API endpoint to issue JWTs and will update README
accordingly. I hope that answers your question.
Best Regards,
Girish
On Sun, Aug 2, 2020 at 3:21 PM Daniel Watford <da...@foomoo.co.uk> wrote:
> Hi Girish,
>
> I wanted to try out some REST calls using Swagger-ui (
> https://localhost:8443/docs/swagger-ui.html) but don't know how to
> authenticate to get a JWT.
>
> Apologies if I missed the instructions elsewhere but please could you
> advise on how to authenticate against the REST api?
>
> Thanks,
>
> Dan.
>
> On Fri, 31 Jul 2020 at 09:34, Girish Vasmatkar <
> girish.vasmatkar@hotwaxsystems.com> wrote:
>
> > Greetings!
> >
> > I have created a PR to add a REST component -
> > https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> > and let me know what you think and let me know if you face any issues. I
> > intend to merge it in a week from now.
> >
> > With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
> > "action" attribute to the service definition now merged, this above
> > component should be able to expose exportable (export=true) and
> > actionable(action=GET|POST) services via REST.
> >
> > Once the changes for nested attributes (OFBIZ-11902
> > <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will
> also
> > be making corresponding changes in the GraphQL plugin to account for
> nested
> > attributes. OFBIZ-11902
> > <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> > help in defining complex GraphQL mutations.
> >
> > I am parallelly also working on designing an XML DSL for REST that should
> > allow tying up REST resources with OFBiz services.
> >
> > Best,
> > Girish
> >
> >
> >
> > On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
> >
> > > Hi Girish,
> > >
> > > Yes, you got it.
> > >
> > > Web browser will popup a login dialog when response code is 401:
> > > setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> > > required\"");
> > >
> > > The popup is skipped and then react/vue/angular can handle the
> response:
> > > setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> > > required\"");
> > >
> > >
> > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > 发送时间: 2020年7月9日 14:54
> > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > 主题: Re: REST implementation
> > >
> > > Hi Shi
> > >
> > > Thanks for taking a look at it. I have a question on "WWW-Authenticate"
> > > header so please clarify and I can make appropriate changes
> accordingly -
> > >
> > > All I am finding is that to prevent the pop-up, either return 403
> (which
> > I
> > > do not want to do) or not include "WWW-Authenticate" header at all (not
> > > inclined to do this as well because then we would be violating the
> spec).
> > > Do you mean to NOT start the value of the header with "Bearer" ?
> > > so instead of below
> > >
> > > *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
> > >
> > > should we change it to
> > >
> > > *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
> > >
> > > I did not test it, but I can just change it like this without testing
> if
> > > you can please confirm it will prevent the browser dialog.
> > >
> > > Thanks again for the review.
> > >
> > > Best,
> > > Girish
> > >
> > > On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com>
> wrote:
> > >
> > > > Hi Girish,
> > > >
> > > > Excellent.
> > > >
> > > > Only one suggestion from my quick view, when response code is 401,
> the
> > > > "WWW-Authenticate" header should be set to start with a word NOT
> > “Bearer
> > > > …”, this can prevent web browser from popping up a login dialog.
> > > >
> > > > Kind Regards,
> > > >
> > > > Shi Jinghai
> > > >
> > > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > > 发送时间: 2020年7月8日 20:47
> > > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > > 主题: Re: REST implementation
> > > >
> > > > Hi Folks
> > > >
> > > > I have added support for OpenApi Integration. The updated code can be
> > > found
> > > > here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> > > > through the changes and test at your end and let me know your
> thoughts.
> > > >
> > > > I am planning to do some refactoring and then raise initial PR for
> the
> > > > plug-in if the changes look good to everyone.
> > > >
> > > > Best,
> > > > Girish
> > > >
> > > >
> > > > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > > > carsten@dcs-verkaufssysteme.de> wrote:
> > > >
> > > > > Hi Girish,
> > > > >
> > > > > Thanks to clarify :)
> > > > > What caught me on the OpenAPI integration is the snippet quoted
> below
> > > and
> > > > > I realize I should have read it in context. Actually then it is
> > aligned
> > > > > with my view.
> > > > >
> > > > > Warm regards
> > > > >
> > > > > Carsten
> > > > >
> > > > > >>>>> Initial implementation does not contain OpenApi integration
> > yet.
> > > > And
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Watford
>
Re: REST implementation
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hi Girish,
I wanted to try out some REST calls using Swagger-ui (
https://localhost:8443/docs/swagger-ui.html) but don't know how to
authenticate to get a JWT.
Apologies if I missed the instructions elsewhere but please could you
advise on how to authenticate against the REST api?
Thanks,
Dan.
On Fri, 31 Jul 2020 at 09:34, Girish Vasmatkar <
girish.vasmatkar@hotwaxsystems.com> wrote:
> Greetings!
>
> I have created a PR to add a REST component -
> https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
> and let me know what you think and let me know if you face any issues. I
> intend to merge it in a week from now.
>
> With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
> "action" attribute to the service definition now merged, this above
> component should be able to expose exportable (export=true) and
> actionable(action=GET|POST) services via REST.
>
> Once the changes for nested attributes (OFBIZ-11902
> <https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
> be making corresponding changes in the GraphQL plugin to account for nested
> attributes. OFBIZ-11902
> <https://issues.apache.org/jira/browse/OFBIZ-11902> will
> help in defining complex GraphQL mutations.
>
> I am parallelly also working on designing an XML DSL for REST that should
> allow tying up REST resources with OFBiz services.
>
> Best,
> Girish
>
>
>
> On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
>
> > Hi Girish,
> >
> > Yes, you got it.
> >
> > Web browser will popup a login dialog when response code is 401:
> > setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> > required\"");
> >
> > The popup is skipped and then react/vue/angular can handle the response:
> > setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> > required\"");
> >
> >
> > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > 发送时间: 2020年7月9日 14:54
> > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > 主题: Re: REST implementation
> >
> > Hi Shi
> >
> > Thanks for taking a look at it. I have a question on "WWW-Authenticate"
> > header so please clarify and I can make appropriate changes accordingly -
> >
> > All I am finding is that to prevent the pop-up, either return 403 (which
> I
> > do not want to do) or not include "WWW-Authenticate" header at all (not
> > inclined to do this as well because then we would be violating the spec).
> > Do you mean to NOT start the value of the header with "Bearer" ?
> > so instead of below
> >
> > *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
> >
> > should we change it to
> >
> > *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
> >
> > I did not test it, but I can just change it like this without testing if
> > you can please confirm it will prevent the browser dialog.
> >
> > Thanks again for the review.
> >
> > Best,
> > Girish
> >
> > On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
> >
> > > Hi Girish,
> > >
> > > Excellent.
> > >
> > > Only one suggestion from my quick view, when response code is 401, the
> > > "WWW-Authenticate" header should be set to start with a word NOT
> “Bearer
> > > …”, this can prevent web browser from popping up a login dialog.
> > >
> > > Kind Regards,
> > >
> > > Shi Jinghai
> > >
> > > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > > 发送时间: 2020年7月8日 20:47
> > > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > > 主题: Re: REST implementation
> > >
> > > Hi Folks
> > >
> > > I have added support for OpenApi Integration. The updated code can be
> > found
> > > here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> > > through the changes and test at your end and let me know your thoughts.
> > >
> > > I am planning to do some refactoring and then raise initial PR for the
> > > plug-in if the changes look good to everyone.
> > >
> > > Best,
> > > Girish
> > >
> > >
> > > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > > carsten@dcs-verkaufssysteme.de> wrote:
> > >
> > > > Hi Girish,
> > > >
> > > > Thanks to clarify :)
> > > > What caught me on the OpenAPI integration is the snippet quoted below
> > and
> > > > I realize I should have read it in context. Actually then it is
> aligned
> > > > with my view.
> > > >
> > > > Warm regards
> > > >
> > > > Carsten
> > > >
> > > > >>>>> Initial implementation does not contain OpenApi integration
> yet.
> > > And
> > > >
> > > >
> > >
> > >
> >
> >
>
--
Daniel Watford
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Greetings!
I have created a PR to add a REST component -
https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
and let me know what you think and let me know if you face any issues. I
intend to merge it in a week from now.
With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
"action" attribute to the service definition now merged, this above
component should be able to expose exportable (export=true) and
actionable(action=GET|POST) services via REST.
Once the changes for nested attributes (OFBIZ-11902
<https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
be making corresponding changes in the GraphQL plugin to account for nested
attributes. OFBIZ-11902
<https://issues.apache.org/jira/browse/OFBIZ-11902> will
help in defining complex GraphQL mutations.
I am parallelly also working on designing an XML DSL for REST that should
allow tying up REST resources with OFBiz services.
Best,
Girish
On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai <hu...@hotmail.com> wrote:
> Hi Girish,
>
> Yes, you got it.
>
> Web browser will popup a login dialog when response code is 401:
> setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
> required\"");
>
> The popup is skipped and then react/vue/angular can handle the response:
> setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
> required\"");
>
>
> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> 发送时间: 2020年7月9日 14:54
> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> 主题: Re: REST implementation
>
> Hi Shi
>
> Thanks for taking a look at it. I have a question on "WWW-Authenticate"
> header so please clarify and I can make appropriate changes accordingly -
>
> All I am finding is that to prevent the pop-up, either return 403 (which I
> do not want to do) or not include "WWW-Authenticate" header at all (not
> inclined to do this as well because then we would be violating the spec).
> Do you mean to NOT start the value of the header with "Bearer" ?
> so instead of below
>
> *WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
>
> should we change it to
>
> *WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
>
> I did not test it, but I can just change it like this without testing if
> you can please confirm it will prevent the browser dialog.
>
> Thanks again for the review.
>
> Best,
> Girish
>
> On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
>
> > Hi Girish,
> >
> > Excellent.
> >
> > Only one suggestion from my quick view, when response code is 401, the
> > "WWW-Authenticate" header should be set to start with a word NOT “Bearer
> > …”, this can prevent web browser from popping up a login dialog.
> >
> > Kind Regards,
> >
> > Shi Jinghai
> >
> > 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> > 发送时间: 2020年7月8日 20:47
> > 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> > 主题: Re: REST implementation
> >
> > Hi Folks
> >
> > I have added support for OpenApi Integration. The updated code can be
> found
> > here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> > through the changes and test at your end and let me know your thoughts.
> >
> > I am planning to do some refactoring and then raise initial PR for the
> > plug-in if the changes look good to everyone.
> >
> > Best,
> > Girish
> >
> >
> > On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> > carsten@dcs-verkaufssysteme.de> wrote:
> >
> > > Hi Girish,
> > >
> > > Thanks to clarify :)
> > > What caught me on the OpenAPI integration is the snippet quoted below
> and
> > > I realize I should have read it in context. Actually then it is aligned
> > > with my view.
> > >
> > > Warm regards
> > >
> > > Carsten
> > >
> > > >>>>> Initial implementation does not contain OpenApi integration yet.
> > And
> > >
> > >
> >
> >
>
>
Re: REST implementation
Posted by Shi Jinghai <hu...@hotmail.com>.
Hi Girish,
Yes, you got it.
Web browser will popup a login dialog when response code is 401:
setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication required\"");
The popup is skipped and then react/vue/angular can handle the response:
setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication required\"");
发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
发送时间: 2020年7月9日 14:54
收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
主题: Re: REST implementation
Hi Shi
Thanks for taking a look at it. I have a question on "WWW-Authenticate"
header so please clarify and I can make appropriate changes accordingly -
All I am finding is that to prevent the pop-up, either return 403 (which I
do not want to do) or not include "WWW-Authenticate" header at all (not
inclined to do this as well because then we would be violating the spec).
Do you mean to NOT start the value of the header with "Bearer" ?
so instead of below
*WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
should we change it to
*WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
I did not test it, but I can just change it like this without testing if
you can please confirm it will prevent the browser dialog.
Thanks again for the review.
Best,
Girish
On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
> Hi Girish,
>
> Excellent.
>
> Only one suggestion from my quick view, when response code is 401, the
> "WWW-Authenticate" header should be set to start with a word NOT “Bearer
> …”, this can prevent web browser from popping up a login dialog.
>
> Kind Regards,
>
> Shi Jinghai
>
> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> 发送时间: 2020年7月8日 20:47
> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> 主题: Re: REST implementation
>
> Hi Folks
>
> I have added support for OpenApi Integration. The updated code can be found
> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> through the changes and test at your end and let me know your thoughts.
>
> I am planning to do some refactoring and then raise initial PR for the
> plug-in if the changes look good to everyone.
>
> Best,
> Girish
>
>
> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> carsten@dcs-verkaufssysteme.de> wrote:
>
> > Hi Girish,
> >
> > Thanks to clarify :)
> > What caught me on the OpenAPI integration is the snippet quoted below and
> > I realize I should have read it in context. Actually then it is aligned
> > with my view.
> >
> > Warm regards
> >
> > Carsten
> >
> > >>>>> Initial implementation does not contain OpenApi integration yet.
> And
> >
> >
>
>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Shi
Thanks for taking a look at it. I have a question on "WWW-Authenticate"
header so please clarify and I can make appropriate changes accordingly -
All I am finding is that to prevent the pop-up, either return 403 (which I
do not want to do) or not include "WWW-Authenticate" header at all (not
inclined to do this as well because then we would be violating the spec).
Do you mean to NOT start the value of the header with "Bearer" ?
so instead of below
*WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*
should we change it to
*WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*
I did not test it, but I can just change it like this without testing if
you can please confirm it will prevent the browser dialog.
Thanks again for the review.
Best,
Girish
On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai <hu...@hotmail.com> wrote:
> Hi Girish,
>
> Excellent.
>
> Only one suggestion from my quick view, when response code is 401, the
> "WWW-Authenticate" header should be set to start with a word NOT “Bearer
> …”, this can prevent web browser from popping up a login dialog.
>
> Kind Regards,
>
> Shi Jinghai
>
> 发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
> 发送时间: 2020年7月8日 20:47
> 收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
> 主题: Re: REST implementation
>
> Hi Folks
>
> I have added support for OpenApi Integration. The updated code can be found
> here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
> through the changes and test at your end and let me know your thoughts.
>
> I am planning to do some refactoring and then raise initial PR for the
> plug-in if the changes look good to everyone.
>
> Best,
> Girish
>
>
> On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
> carsten@dcs-verkaufssysteme.de> wrote:
>
> > Hi Girish,
> >
> > Thanks to clarify :)
> > What caught me on the OpenAPI integration is the snippet quoted below and
> > I realize I should have read it in context. Actually then it is aligned
> > with my view.
> >
> > Warm regards
> >
> > Carsten
> >
> > >>>>> Initial implementation does not contain OpenApi integration yet.
> And
> >
> >
>
>
Re: REST implementation
Posted by Shi Jinghai <hu...@hotmail.com>.
Hi Girish,
Excellent.
Only one suggestion from my quick view, when response code is 401, the "WWW-Authenticate" header should be set to start with a word NOT “Bearer …”, this can prevent web browser from popping up a login dialog.
Kind Regards,
Shi Jinghai
发件人: Girish Vasmatkar<ma...@hotwaxsystems.com>
发送时间: 2020年7月8日 20:47
收件人: dev@ofbiz.apache.org<ma...@ofbiz.apache.org>
主题: Re: REST implementation
Hi Folks
I have added support for OpenApi Integration. The updated code can be found
here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
through the changes and test at your end and let me know your thoughts.
I am planning to do some refactoring and then raise initial PR for the
plug-in if the changes look good to everyone.
Best,
Girish
On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
carsten@dcs-verkaufssysteme.de> wrote:
> Hi Girish,
>
> Thanks to clarify :)
> What caught me on the OpenAPI integration is the snippet quoted below and
> I realize I should have read it in context. Actually then it is aligned
> with my view.
>
> Warm regards
>
> Carsten
>
> >>>>> Initial implementation does not contain OpenApi integration yet. And
>
>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Folks
I have added support for OpenApi Integration. The updated code can be found
here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
through the changes and test at your end and let me know your thoughts.
I am planning to do some refactoring and then raise initial PR for the
plug-in if the changes look good to everyone.
Best,
Girish
On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
carsten@dcs-verkaufssysteme.de> wrote:
> Hi Girish,
>
> Thanks to clarify :)
> What caught me on the OpenAPI integration is the snippet quoted below and
> I realize I should have read it in context. Actually then it is aligned
> with my view.
>
> Warm regards
>
> Carsten
>
> >>>>> Initial implementation does not contain OpenApi integration yet. And
>
>
Re: REST implementation
Posted by Carsten Schinzer <ca...@dcs-verkaufssysteme.de>.
Hi Girish,
Thanks to clarify :)
What caught me on the OpenAPI integration is the snippet quoted below and I realize I should have read it in context. Actually then it is aligned with my view.
Warm regards
Carsten
>>>>> Initial implementation does not contain OpenApi integration yet. And
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Carsten
OpenAPI integration and the implementation go hand in hand so no reason
separating them. I think what this draft does is just trying to see how
this might work. I am also parallelly working on OpenAPI spec but I wanted
the developers to review this work to get a better understanding of how to
proceed further.
As for the PATCH example that I quoted, that was just for
demonstration purposes to show the two approaches.
Best Regards,
Girish
On Wed, Jun 17, 2020 at 2:42 PM Carsten Schinzer <
carsten@dcs-verkaufssysteme.de> wrote:
> Hello Giresh,
>
>
> Thanks for the example, it makes clearer what you want to achieve.
>
> General considerations on RESTful or not:
> If you want to stop a productionRun, why do you use PATCH and not DELETE?
> Well, I know the connotation of Delete is „dismantle“ rather than „stop“,
> but PATCH also considers and exposes config/data changes, not only status
> changes
>
> PATCH /rest/productionruns/{productionRunId}?action=cancel
> … would probably be the best
>
> Here is how an Annotation based implementation would achieve this:
>
> @Route /productionrun/{productionRunId}, requirement={productionRunid, \d+}
> @ApiDoc(title=„A service to patch MRP Production Runs“, description="It
> allows to change the run configuration and status“)
> public patchProductionRunAction(int productionRunId, string[]
> urlParameters)
> {
> ...
> if urlParameters[‚action‘] == ‚cancel‘:
> call service cancelProductionRun(productionRunId)
> ...
> }
>
> Forgive this pseudo-code, but I think you get what I mean.
>
> It would not avoid that some matching layer of code is reuqired in-between
> the exposed REST API methods like patchProductionRunAction and the actual
> service call, but this layer would remain code instead of being in XML or
> somewhere else that requires a context switch.
>
> In my other application (the PHP) the classes are clearly separated by
> responsibility, i.e. Repository classes interact wit the persistence layer,
> Service classes are manipulating things and RestController classes are
> wrapping up the REST API methods and properly annotated with the Routes and
> validation constraints. The important point is that it is all coded in the
> same language and therefore the context is exposed to the IDE I am working
> with. No lookups to be made into an XML file to understand parameters and
> return types of services etc. That is quite an advantage IMO.
>
> IMO that is the complexity in the current way of dealing with this in
> OFBiz and that’s why I believe the OpenAPI integration should be going
> along with REST implementation.
>
> Warm regards
>
>
> Carsten
>
>
> > Am 17.06.2020 um 08:38 schrieb Girish Vasmatkar <
> girish.vasmatkar@hotwaxsystems.com>:
> >
> > Hi Carsten -
> >
> > Your points make a lot of sense and that's the general consensus of the
> > community as well. However, I believe we want to have the option of
> > exposing the services via "REST". The existing frameworks services
> > obviously are not named, thinking them as Resources and in the REST work
> > resources are perceived as nouns.
> >
> > This is obviously not a complete implementation and we would obviously
> like
> > to tie up entities and services with resources. For example - consider
> the
> > service cancelProductionRun.
> >
> > If we expose it under services resource (considering services as
> > resources), we could do it like this -
> > PATCH /rest/services/cancelProductionRun
> > {
> > "productionRunId": 1234
> > }
> >
> > While this may not sound RESTFul, but this in a way adds capability for
> > OFBiz to expose the services via a "REST" interface. A truly RESTFul
> > approach that I am working on might do something like this -
> >
> > PATCH /rest/productionruns/{productionRunId}
> >
> > Internally it will hook up the service cancelProductionRun with this
> > resource URL. This obviously has to be configured somewhere in XML and
> such
> > details can be chalked out.
> >
> > Best,
> > Girish
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
> > jacques.le.roux@les7arts.com> wrote:
> >
> >> 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.kute@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.roux@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
> >>>>>
> >>
>
>
Re: REST implementation
Posted by Carsten Schinzer <ca...@dcs-verkaufssysteme.de>.
Hello Giresh,
Thanks for the example, it makes clearer what you want to achieve.
General considerations on RESTful or not:
If you want to stop a productionRun, why do you use PATCH and not DELETE? Well, I know the connotation of Delete is „dismantle“ rather than „stop“, but PATCH also considers and exposes config/data changes, not only status changes
PATCH /rest/productionruns/{productionRunId}?action=cancel
… would probably be the best
Here is how an Annotation based implementation would achieve this:
@Route /productionrun/{productionRunId}, requirement={productionRunid, \d+}
@ApiDoc(title=„A service to patch MRP Production Runs“, description="It allows to change the run configuration and status“)
public patchProductionRunAction(int productionRunId, string[] urlParameters)
{
...
if urlParameters[‚action‘] == ‚cancel‘:
call service cancelProductionRun(productionRunId)
...
}
Forgive this pseudo-code, but I think you get what I mean.
It would not avoid that some matching layer of code is reuqired in-between the exposed REST API methods like patchProductionRunAction and the actual service call, but this layer would remain code instead of being in XML or somewhere else that requires a context switch.
In my other application (the PHP) the classes are clearly separated by responsibility, i.e. Repository classes interact wit the persistence layer, Service classes are manipulating things and RestController classes are wrapping up the REST API methods and properly annotated with the Routes and validation constraints. The important point is that it is all coded in the same language and therefore the context is exposed to the IDE I am working with. No lookups to be made into an XML file to understand parameters and return types of services etc. That is quite an advantage IMO.
IMO that is the complexity in the current way of dealing with this in OFBiz and that’s why I believe the OpenAPI integration should be going along with REST implementation.
Warm regards
Carsten
> Am 17.06.2020 um 08:38 schrieb Girish Vasmatkar <gi...@hotwaxsystems.com>:
>
> Hi Carsten -
>
> Your points make a lot of sense and that's the general consensus of the
> community as well. However, I believe we want to have the option of
> exposing the services via "REST". The existing frameworks services
> obviously are not named, thinking them as Resources and in the REST work
> resources are perceived as nouns.
>
> This is obviously not a complete implementation and we would obviously like
> to tie up entities and services with resources. For example - consider the
> service cancelProductionRun.
>
> If we expose it under services resource (considering services as
> resources), we could do it like this -
> PATCH /rest/services/cancelProductionRun
> {
> "productionRunId": 1234
> }
>
> While this may not sound RESTFul, but this in a way adds capability for
> OFBiz to expose the services via a "REST" interface. A truly RESTFul
> approach that I am working on might do something like this -
>
> PATCH /rest/productionruns/{productionRunId}
>
> Internally it will hook up the service cancelProductionRun with this
> resource URL. This obviously has to be configured somewhere in XML and such
> details can be chalked out.
>
> Best,
> Girish
>
>
>
>
>
>
>
>
>
>
> On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> 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.kute@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.roux@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
>>>>>
>>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Carsten -
Your points make a lot of sense and that's the general consensus of the
community as well. However, I believe we want to have the option of
exposing the services via "REST". The existing frameworks services
obviously are not named, thinking them as Resources and in the REST work
resources are perceived as nouns.
This is obviously not a complete implementation and we would obviously like
to tie up entities and services with resources. For example - consider the
service cancelProductionRun.
If we expose it under services resource (considering services as
resources), we could do it like this -
PATCH /rest/services/cancelProductionRun
{
"productionRunId": 1234
}
While this may not sound RESTFul, but this in a way adds capability for
OFBiz to expose the services via a "REST" interface. A truly RESTFul
approach that I am working on might do something like this -
PATCH /rest/productionruns/{productionRunId}
Internally it will hook up the service cancelProductionRun with this
resource URL. This obviously has to be configured somewhere in XML and such
details can be chalked out.
Best,
Girish
On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> 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.kute@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.roux@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
> >>>
>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <pr...@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.roux@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
>>>
Re: REST implementation
Posted by Carsten Schinzer <ca...@dcs-verkaufssysteme.de>.
Hello,
Certainly +1 for a REST API Implementation including JWT.
I am implementing a REST API for internal use in my job based upon PHP and Symfony framework (FOS REST and NELMIO Bundle just in case someone is interested) and find VERY cool that the NELMIO API Doc Bundle comes with an adopted Swagger documentation done through Annotations on the documentation comment for the very method implementation, i.e. avoiding the various different files to define the invocation, URI endpoint, implementation.
A good REST API design usually obsoletes the need to include the CRUD action into service naming (createXService, updateYService, ...). I liked the following article most and have implemented along this guidelines on my internal tool mentioned above: https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api <https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api>.
It is a bit trickier to keep a good overview of verbs & methods on such APIs, but that can easily be handled by warnings/errors at Integration time. And the generated API documentation is always your friend, too!
I would therefore prefer to combine a REST API implementation with OpenAPI integration right away. Maybe worth a dedicated discussion and kick-off in the upcoming Community Days in August? Could be worth a dedicated team / slack channel that aligns on major concepts and side-by-side options of Service Engine vs. OpenAPI and gets a first implementation going.
If we decide to take that path, there will be interference with the Service Engine view and the Swagger Documentation will replace it on the long run I would expect. We would also need to consider cross-effects onto the Minilang-to-GroovyDSL migration. Design and Architecture decisions made could mean a change of direction on that activity.
Hope my 0.02 EUR make sense.
Warm regards
Carsten
> Am 15.06.2020 um 17:59 schrieb Girish Vasmatkar <gi...@hotwaxsystems.com>:
>
> 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 <pr...@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.roux@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
>>>
>>>
>>
Re: REST implementation
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
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 <pr...@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.roux@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
> >
> >
>
Re: REST implementation
Posted by Pritam Kute <pr...@hotwaxsystems.com>.
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.roux@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
>
>
Re: REST implementation
Posted by Jacques Le Roux <ja...@les7arts.com>.
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