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