OFBIZ-11995

[grv]

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

[Ravi Lodhi]

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 <
[hidden email]> 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
>

[grv]

Hi Ravi

Please find my comments in-line below...

On Thu, Oct 22, 2020 at 7:38 PM Ravi Lodhi <[hidden email]> 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 <
> [hidden email]> 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
> >
>

[Ravi Lodhi]

Makes sense. Thanks for the explanation!

On Sat, Oct 24, 2020 at 12:58 PM Girish Vasmatkar <
[hidden email]> wrote:

> Hi Ravi
>
> Please find my comments in-line below...
>
> On Thu, Oct 22, 2020 at 7:38 PM Ravi Lodhi <[hidden email]> 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 <
> > [hidden email]> 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
> > >
> >
>