[Engine-devel] REST API calls from the GUI

Wed Feb 20 12:45:02 UTC 2013

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Kanagaraj Mayilsamy" <kmayilsa at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
> Sent: Wednesday, February 20, 2013 5:55:50 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:
> > 
> > 
> > ----- 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.
> 
> why? they only have jaxb annotations which are 'must' for
> serialization & talking with api.
> 

We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation

If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by 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
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 