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