On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: > > > ----- Original Message ----- >> From: "Vojtech Szocs" <vsz...@redhat.com> >> To: "Daniel Erez" <de...@redhat.com> >> Cc: a...@ovirt.org, engine-devel@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. > >> Vojtech >> >> >> ----- Original Message ----- >> From: "Daniel Erez" <de...@redhat.com> >> To: "Michael Pasternak" <mpast...@redhat.com> >> Cc: engine-devel@ovirt.org, "Einav Cohen" <eco...@redhat.com>, >> a...@ovirt.org, "Libor Spevak" <lspe...@redhat.com>, "Vojtech Szocs" >> <vsz...@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" <mpast...@redhat.com> >>> To: "Libor Spevak" <lspe...@redhat.com> >>> Cc: engine-devel@ovirt.org, "Daniel Erez" <de...@redhat.com>, >>> "Gilad Chaplik" <gchap...@redhat.com>, "Einav Cohen" >>> <eco...@redhat.com>, a...@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@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
