Re: OFBIZ-11995

[Ravi Lodhi]

Makes sense. Thanks for the explanation!

On Sat, Oct 24, 2020 at 12:58 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hi Ravi
>
> Please find my comments in-line below...
>
> On Thu, Oct 22, 2020 at 7:38 PM Ravi Lodhi  wrote:
>
> > Hello Girish,
> >
> > The XML-based REST DSL is a great enhancement and gives much more
> > flexibility to define the rest endpoints. I just tried out some REST
> APIs.
> > The only thing I noticed so far is regarding the way the query parameters
> > are passed to a GET call.
> >
> > The /rest/services/* GET endpoints requires URL encoded JSON in query
> param
> > as given below -
> >
> > curl -G -X  GET https://localhost:8443/rest/services/findProductById
> > --data-urlencod
> > 
> > 'inParams={"idToFind":"GZ-1001"}' -H "Accept:
> > application/json" -H "Authorization: Bearer
> >
> >
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJ1c2VyTG9naW5JZCI6ImFkbWluIiwiaXNzIjoiQXBhY2hlT0ZCaXoiLCJleHAiOjE2MDMzNzU2ODksImlhdCI6MTYwMzM3Mzg4OX0.izqiW-bOXFHOm5Nk_ZFQ2PpfPtrcUM8y_5FnT-5UgEKeNv-sw0J2zq3OI1dACjPC8tCUJjFnOb3zt2ozpGOGmQ"
> > --insecure
> >
> >  GV: Service endpoints and XML DSLs were implemented in isolation. The
> service endpoint impl was done first and at that time I had thought to
> design it in a way that allows to send individual service IN params.
> However, due to the fact that someone might want to use an existing service
> with a lot of IN params with GET action possibly making the URL too large.
> Having individual IN params as query params certainly make it a bit more
> intuitive for the API consumer, but this was the reason behind it. However,
> after I implemented REST DSL, the GET implementation with more RESTFul URL
> patterns, the individual IN params as query params made more natural and
> sensible.
>
> I will probably make both consistent as I now feel that the REST DSL
> approach is a bit more intuitive and straightforward. I hope this answers
> your questions.
>
>
> >
> > While the REST DSL GET endpoints requires query parameters directly as
> > given below-
> >
> > curl -G -X  GET https://localhost:8443/rest/products?idToFind=GZ-1001 -H
> > "Accept: application/json" -H "Authorization: Bearer
> >
> >
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJ1c2VyTG9naW5JZCI6ImFkbWluIiwiaXNzIjoiQXBhY2hlT0ZCaXoiLCJleHAiOjE2MDMzNzU2ODksImlhdCI6MTYwMzM3Mzg4OX0.izqiW-bOXFHOm5Nk_ZFQ2PpfPtrcUM8y_5FnT-5UgEKeNv-sw0J2zq3OI1dACjPC8tCUJjFnOb3zt2ozpGOGmQ"
> > --insecure
> >
> > Is there any specific reason behind this? Can we make it consistent?
> >
> > Kind Regards,
> > --
> > Ravi Lodhi
> >
> > On Wed, Sep 23, 2020 at 7:09 PM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> > > Hi All
> > >
> > > Continuing the efforts done on OFBIZ-11328, I have now added an XML
> based
> > > REST DSL that facilitates declarative resource bindings to OFBiz
> services
> > > (for now only OFBiz service).  Various commits are pushed under
> > > OFBIZ-11995.
> > > It attempts to allow each component to define their own set of APIs
> that
> > > eventually end up being in a single runtime. At the moment, a single
> > > OpenAPI spec (JSON and YAML) is generated clubbing together APIs
> defined
> > in
> > > all components. I wish to provide separate OpenAPI for each component
> > > considering the combined spec becomes too huge.
> > >
> > > I have also developed a demo component under my forked plug-in to give
> > you
> > > an idea of how the resources can be defined and mapped to OFBiz
> services.
> > > Pl take a look at -
> > >
> >
> https://github.com/girishvasmatkar/ofbiz-plugins/tree/trunk/rest-impl-demo
> > >
> > > In the demo, I have configured some resources like below -
> > >
> > > POST  /rest*/*products (Create a new product)
> > > GET /rest/products/{productId} (Get product)
> > > POST /rest/products/features (Create a new feature)
> > > POST /rest/products/{productId}/features (Apply feature to product)
> > > GET /rest/products/{productId}/features/{featureId}
> > >
> > > POST /rest/categories (Create a new category)
> > > GET /rest/categories (Get all categories)
> > >
> > > Schema file can be defined under
> > > /api/.rest.xml
> > >
> > > For now, JSON is supported and I intend to bring in XML in the mix as
> > well
> > > based on the Content-Type header.
> > > There may be some refinement needed and some extra use cases that may
> not
> > > work, so please feel free to let me know how it goes and any changes
> you
> > > would like to make and I will try to accomodate.
> > >
> > > Best,
> > > Girish
> > > HotWax Systems
> > >
> >
>

Re: OFBIZ-11995

[Girish Vasmatkar]

Hi Ravi

Please find my comments in-line below...

On Thu, Oct 22, 2020 at 7:38 PM Ravi Lodhi  wrote:

> Hello Girish,
>
> The XML-based REST DSL is a great enhancement and gives much more
> flexibility to define the rest endpoints. I just tried out some REST APIs.
> The only thing I noticed so far is regarding the way the query parameters
> are passed to a GET call.
>
> The /rest/services/* GET endpoints requires URL encoded JSON in query param
> as given below -
>
> curl -G -X  GET https://localhost:8443/rest/services/findProductById
> --data-urlencod
> 
> 'inParams={"idToFind":"GZ-1001"}' -H "Accept:
> application/json" -H "Authorization: Bearer
>
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJ1c2VyTG9naW5JZCI6ImFkbWluIiwiaXNzIjoiQXBhY2hlT0ZCaXoiLCJleHAiOjE2MDMzNzU2ODksImlhdCI6MTYwMzM3Mzg4OX0.izqiW-bOXFHOm5Nk_ZFQ2PpfPtrcUM8y_5FnT-5UgEKeNv-sw0J2zq3OI1dACjPC8tCUJjFnOb3zt2ozpGOGmQ"
> --insecure
>
>  GV: Service endpoints and XML DSLs were implemented in isolation. The
service endpoint impl was done first and at that time I had thought to
design it in a way that allows to send individual service IN params.
However, due to the fact that someone might want to use an existing service
with a lot of IN params with GET action possibly making the URL too large.
Having individual IN params as query params certainly make it a bit more
intuitive for the API consumer, but this was the reason behind it. However,
after I implemented REST DSL, the GET implementation with more RESTFul URL
patterns, the individual IN params as query params made more natural and
sensible.

I will probably make both consistent as I now feel that the REST DSL
approach is a bit more intuitive and straightforward. I hope this answers
your questions.


>
> While the REST DSL GET endpoints requires query parameters directly as
> given below-
>
> curl -G -X  GET https://localhost:8443/rest/products?idToFind=GZ-1001 -H
> "Accept: application/json" -H "Authorization: Bearer
>
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJ1c2VyTG9naW5JZCI6ImFkbWluIiwiaXNzIjoiQXBhY2hlT0ZCaXoiLCJleHAiOjE2MDMzNzU2ODksImlhdCI6MTYwMzM3Mzg4OX0.izqiW-bOXFHOm5Nk_ZFQ2PpfPtrcUM8y_5FnT-5UgEKeNv-sw0J2zq3OI1dACjPC8tCUJjFnOb3zt2ozpGOGmQ"
> --insecure
>
> Is there any specific reason behind this? Can we make it consistent?
>
> Kind Regards,
> --
> Ravi Lodhi
>
> On Wed, Sep 23, 2020 at 7:09 PM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
> > Hi All
> >
> > Continuing the efforts done on OFBIZ-11328, I have now added an XML based
> > REST DSL that facilitates declarative resource bindings to OFBiz services
> > (for now only OFBiz service).  Various commits are pushed under
> > OFBIZ-11995.
> > It attempts to allow each component to define their own set of APIs that
> > eventually end up being in a single runtime. At the moment, a single
> > OpenAPI spec (JSON and YAML) is generated clubbing together APIs defined
> in
> > all components. I wish to provide separate OpenAPI for each component
> > considering the combined spec becomes too huge.
> >
> > I have also developed a demo component under my forked plug-in to give
> you
> > an idea of how the resources can be defined and mapped to OFBiz services.
> > Pl take a look at -
> >
> https://github.com/girishvasmatkar/ofbiz-plugins/tree/trunk/rest-impl-demo
> >
> > In the demo, I have configured some resources like below -
> >
> > POST  /rest*/*products (Create a new product)
> > GET /rest/products/{productId} (Get product)
> > POST /rest/products/features (Create a new feature)
> > POST /rest/products/{productId}/features (Apply feature to product)
> > GET /rest/products/{productId}/features/{featureId}
> >
> > POST /rest/categories (Create a new category)
> > GET /rest/categories (Get all categories)
> >
> > Schema file can be defined under
> > /api/.rest.xml
> >
> > For now, JSON is supported and I intend to bring in XML in the mix as
> well
> > based on the Content-Type header.
> > There may be some refinement needed and some extra use cases that may not
> > work, so please feel free to let me know how it goes and any changes you
> > would like to make and I will try to accomodate.
> >
> > Best,
> > Girish
> > HotWax Systems
> >
>

Re: I would like to contribute

[Deepak Dixit]

Thanks Madhu, now your email has been delivered to the dev list properly.

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Sat, Oct 24, 2020 at 12:24 PM Madhu Mohan 
wrote:

> Hi Deepak,
>
> I have subscribed already, sent an email to the dev group. Please let me
> know if I am added to subscribers list.
>
>
>
> Best Regards
> Madhu
>
> On Sat, 24 Oct 2020 at 14:20, Deepak Dixit  wrote:
>
>> Hi Madhu,
>>
>> Your message has been moderated, else it would not have reached this
>> Mailing List.
>>
>> Please subscribe to the mailing list, See why here
>> http://ofbiz.apache.org/mailing-lists.html.
>>
>> You will get better support, people can answer you on the ML. The wider
>> the
>> audience the better the answers you might get.
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> ofbiz.apache.org
>>
>>
>> On Sat, Oct 24, 2020 at 11:50 AM Madhu Mohan 
>> wrote:
>>
>>> Hi,
>>> I would like to add a billing plugin to Ofbiz. But before that I need
>>> certain information on the existing services which I don't find much
>>> information online. Can someone please help me.
>>>
>>> Best Regards
>>> Madhu
>>>
>>

Re: I would like to contribute

[Madhu Mohan]

Hi Deepak,

I have subscribed already, sent an email to the dev group. Please let me
know if I am added to subscribers list.



Best Regards
Madhu

On Sat, 24 Oct 2020 at 14:20, Deepak Dixit  wrote:

> Hi Madhu,
>
> Your message has been moderated, else it would not have reached this
> Mailing List.
>
> Please subscribe to the mailing list, See why here
> http://ofbiz.apache.org/mailing-lists.html.
>
> You will get better support, people can answer you on the ML. The wider the
> audience the better the answers you might get.
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Sat, Oct 24, 2020 at 11:50 AM Madhu Mohan 
> wrote:
>
>> Hi,
>> I would like to add a billing plugin to Ofbiz. But before that I need
>> certain information on the existing services which I don't find much
>> information online. Can someone please help me.
>>
>> Best Regards
>> Madhu
>>
>

Re: I would like to contribute

[Deepak Dixit]

Hi Madhu,

Your message has been moderated, else it would not have reached this
Mailing List.

Please subscribe to the mailing list, See why here
http://ofbiz.apache.org/mailing-lists.html.

You will get better support, people can answer you on the ML. The wider the
audience the better the answers you might get.

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Sat, Oct 24, 2020 at 11:50 AM Madhu Mohan 
wrote:

> Hi,
> I would like to add a billing plugin to Ofbiz. But before that I need
> certain information on the existing services which I don't find much
> information online. Can someone please help me.
>
> Best Regards
> Madhu
>

I would like to contribute

[Madhu Mohan]

Hi,
I would like to add a billing plugin to Ofbiz. But before that I need certain 
information on the existing services which I don't find much information 
online. Can someone please help me.

Best Regards
Madhu