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 <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 > > > > > >
