You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ravi Lodhi <lo...@gmail.com> on 2020/10/22 14:07:36 UTC
Re: OFBIZ-11995
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
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.vasmatkar@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
> <component-root>/api/<component-name>.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
Posted by Ravi Lodhi <lo...@gmail.com>.
Makes sense. Thanks for the explanation!
On Sat, Oct 24, 2020 at 12:58 PM Girish Vasmatkar <
girish.vasmatkar@hotwaxsystems.com> wrote:
> Hi Ravi
>
> Please find my comments in-line below...
>
> On Thu, Oct 22, 2020 at 7:38 PM Ravi Lodhi <lo...@gmail.com> 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
> > <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.vasmatkar@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
> > > <component-root>/api/<component-name>.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
Posted by Girish Vasmatkar <gi...@hotwaxsystems.com>.
Hi Ravi
Please find my comments in-line below...
On Thu, Oct 22, 2020 at 7:38 PM Ravi Lodhi <lo...@gmail.com> 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
> <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.vasmatkar@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
> > <component-root>/api/<component-name>.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
> >
>