[Engine-devel] REST API calls from the GUI

Mon Feb 18 03:09:45 UTC 2013

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: arch at ovirt.org, engine-devel at ovirt.org
> Sent: Saturday, February 16, 2013 1:07:56 AM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> Hi Daniel,
> 
> > The first alternative can be implemented by using GWT
> > RequestBuilder (for sending the HTTP requests)
> > and GWT overlay types (that can be generated from java POJOs).
> > Probably best performance-wise/less data type conversions/etc;
> > However, basically means writing a JavaScript SDK.
> 
> Yes, we can use RequestBuilder for making AJAX HTTP requests, but
> using GWT overlay types is possible only if REST API fully supports
> JSON format. In case of XML format, we would have to use GWT
> XMLParser to map "restapi-types" entities/collections to/from XML
> strings, e.g. we could write GWT deferred binding generators to
> generate such mappers from current schema.

AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically.

> 
> > The benefit of the second alternative is currently rather vague
> > since the Java SDK can't be converted to JavaScript as is
> > (can't use apache.commons and javax packages in GWT client side).
> > Need to check how easily they can be replaced
> > with JRE libraries that GWT can emulate (for supporting both GWT
> > web and debug mode).
> 
> Indeed, we can't use Java REST API SDK as it is with GWT:
> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
> 
> This means we need to implement our own transport layer
> (RequestBuilder) and most likely also the marshalling layer
> (XMLParser vs. JSONParser vs. overlay types).

It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK. 

> 
> > A third alternative could be simply maintaining the current GWT RPC
> > mechanism we use.
> > I.e. integrating the Java SDK into the GWT servlet, which means
> > wrapping the API into GenericApiGWTService.
> > The main drawback is an additional layer of data type conversion
> > and round-trip:
> > Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> 
> This is interesting, generic API could be used to transfer
> "restapi-types", along with extra information to emulate proper HTTP
> request, without any marshalling involved.
> 

We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. 

> Vojtech
> 
> 
> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: engine-devel at ovirt.org, "Einav Cohen" <ecohen at redhat.com>,
> arch at ovirt.org, "Libor Spevak" <lspevak at redhat.com>, "Vojtech Szocs"
> <vszocs at redhat.com>
> Sent: Friday, February 15, 2013 7:17:43 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "Libor Spevak" <lspevak at redhat.com>
> > Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>,
> > "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
> > <ecohen at redhat.com>, arch at ovirt.org
> > Sent: Wednesday, February 13, 2013 12:55:36 PM
> > Subject: Re: [Engine-devel] REST API calls from the GUI
> > 
> > 
> > Hi Libor,
> > 
> > This issue came across in one of the conversations i had with UX
> > folks, but since we didn't end
> > up with any conclusion/road map (nor discussed it properly to hear
> > other thoughts), this is a perfect
> > place to start this discussion,
> > 
> > Intuitively REST is a way to go with GWT AJAX calls
> > ---------------------------------------------------
> > 
> > pros
> > ====
> > 
> > - api data objects can be reused by generating java classes (using
> > jaxb) from the rest schema [1]
> > - no backend logic will be duplicated as api abstracts the backend
> > exposing RESTful collection/resources to operate on
> > - development against api is "easy" as api describes itself in RSDL
> > [2]
> > 
> > cons
> > ====
> > 
> > - implementing transport layer (HTTP) under GWT
> > - implementing own j2xml/json/yaml/... marshalling layer
> > - implementing own error handling mechanism
> > - implementing REST callback mechanism (in GWT)
> > - constant maintenance of the data objects generated from the api
> > - painful for Java developers
> > 
> > Java-SDK
> > --------
> > 
> > pros
> > ====
> > 
> > - abstracts transport layer (leaving developer in standard Java
> > api)
> > - typesafe code (no need to mess with XML bulks)
> > - has own data objects to work with
> > - abstracts authentication/authorization
> > (kerberos/cookie/session/etc.)
> > - since SDK is auto-generated, it can be easily extended with
> > required
> >   features to support UI (such as callback infrastructure for
> >   instance)
> > 
> > cons
> > ====
> > 
> > - has to be converted in to Javascript (not sure what the impacts
> > are
> > in terms of AJAX calls/etc.)
> > - probably much more cons that we're not aware of and will have to
> > figure out with POC
> > 
> > 
> > thoughts?
> 
> 
> The first alternative can be implemented by using GWT RequestBuilder
> (for sending the HTTP requests)
> and GWT overlay types (that can be generated from java POJOs).
> Probably best performance-wise/less data type conversions/etc;
> However, basically means writing a JavaScript SDK.
> 
> The benefit of the second alternative is currently rather vague since
> the Java SDK can't be converted to JavaScript as is
> (can't use apache.commons and javax packages in GWT client side).
> Need to check how easily they can be replaced
> with JRE libraries that GWT can emulate (for supporting both GWT web
> and debug mode).
> 
> A third alternative could be simply maintaining the current GWT RPC
> mechanism we use.
> I.e. integrating the Java SDK into the GWT servlet, which means
> wrapping the API into GenericApiGWTService.
> The main drawback is an additional layer of data type conversion and
> round-trip:
> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> 
> 
> > 
> > [1] http[s]://server[:port]/api?schema
> > [2] http[s]://server[:port]/api?rsdl
> > 
> > On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > > Hi,
> > > 
> > > I would like to ask, if there have been discussions about an
> > > option
> > > to call REST API services directly from the Frontend (GWT layer)?
> > > GWT compiles Java frontend-side to
> > > Javascript, calls to backend services are performed
> > > "transparently"
> > > by the framework using AJAX support. But, there is still a need
> > > to
> > > have a special set of data objects
> > > and the server-side logic can duplicate.
> > > 
> > > Java REST API SDK enables to build "thick" client. The calls are
> > > realized using e.g. Apache HttClient and supported libraries. I
> > > think the requirements of GWT can be a
> > > little bit different, but something overlaps.
> > > 
> > > I found several links about REST API support from GWT, so there
> > > is
> > > something for inspiration...
> > > 
> > > - http://www.spiffyui.org/
> > > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > > - http://code.google.com/p/gwt-rest/
> > > - http://restygwt.fusesource.org/
> > > 
> > > But, do you think it would be useful and what drawbacks can occur
> > > (authentication, authorization, response times, need to support
> > > larger set of services, painful
> > > refactoring, ...)?
> > > 
> > > Regards,
> > > Libor
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > --
> > 
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 