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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Christopher Morrissey" <Christopher.Morrissey(a)netapp.com&gt; To: "Keith Robertson" <kroberts(a)redhat.com&gt;, "Libor Spevak" <lspevak(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Tuesday, February 12, 2013 5:53:52 PM Subject: RE: [Engine-devel] REST API calls from the GUI The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code. http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html -Chris > -----Original Message----- > From: engine-devel-bounces(a)ovirt.org [mailto:engine-devel- > bounces(a)ovirt.org] On Behalf Of Keith Robertson > Sent: Tuesday, February 12, 2013 11:30 AM > To: Libor Spevak > Cc: engine-devel(a)ovirt.org > Subject: Re: [Engine-devel] REST API calls from the GUI > > Not sure if this is possible now but, I would like the front-end to > expose an > authenticated hook to the API so that plug-ins can call RESTful > methods. It > would enable plug-in writers to do all sorts of interesting things > in their plug- > ins with the RESTful API. > > Cheers, > Keith > > On 02/12/2013 11:13 AM, 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(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

Hi Libor, > 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. Indeed, for both WebAdmin and UserPortal, we're planning to move away from GWT RPC (a.k.a Generic API) and use Engine REST API and promote loose coupling between client and server. As Chris mentioned, for WebAdmin UI plugins, there's already support for calling Engine REST API - session ID is obtained upon WebAdmin UI login and passed to all UI plugins. It's up to plugin authors to decide if the plugin itself (JavaScript) will communicate via REST API, or if the plugin passes the session ID to some other server so that the other server does REST API communication. > 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. Well, we can't really use Java REST API SDK directly due to restrictions imposed by GWT on client-side code, e.g. HttClient uses sockets which are (obviously) not supported in JavaScript and therefore related classes are rejected by GWT compiler. What we're planning to do is to map REST API XML responses to generated "REST API Types" (based on api.xsd schema) and vice versa. This could be a bit of challenge, as most frameworks for GWT REST API support use JSON representation in favor of XML.

Vojtech ----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey(a)netapp.com&gt; To: "Keith Robertson" <kroberts(a)redhat.com&gt;, "Libor Spevak" <lspevak(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Tuesday, February 12, 2013 11:53:52 PM Subject: Re: [Engine-devel] REST API calls from the GUI The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code. http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html -Chris > -----Original Message----- > From: engine-devel-bounces(a)ovirt.org [mailto:engine-devel- > bounces(a)ovirt.org] On Behalf Of Keith Robertson > Sent: Tuesday, February 12, 2013 11:30 AM > To: Libor Spevak > Cc: engine-devel(a)ovirt.org > Subject: Re: [Engine-devel] REST API calls from the GUI > > Not sure if this is possible now but, I would like the front-end to expose an > authenticated hook to the API so that plug-ins can call RESTful methods. It > would enable plug-in writers to do all sorts of interesting things in their plug- > ins with the RESTful API. > > Cheers, > Keith > > On 02/12/2013 11:13 AM, 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message ----- > From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > To: "Libor Spevak" <lspevak(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, arch(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? > > [1] http[s]://server[:port]/api?schema > [2] http[s]://server[:port]/api?rsdl > Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context?

> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Arch mailing list > Arch(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch >

From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; To: "Michael Pasternak" <mpastern(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from ----- Original Message ----- > From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > Sent: Wednesday, February 20, 2013 2:56:59 PM > Subject: Re: [Engine-devel] REST API calls from > > On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > > > > ----- Original Message ----- > >> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > >> To: "Libor Spevak" <lspevak(a)redhat.com&gt; > >> Cc: engine-devel(a)ovirt.org, arch(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? > >> > >> [1] http[s]://server[:port]/api?schema > >> [2] http[s]://server[:port]/api?rsdl > >> > > > > Although started as a UI request, there are other needs who wish > > to use API calls with a different transport. For example a > > backend > > hook which gets a REST entry point it can use to fetch for > > additional > > data, or perform actions. In this case I'd expect an internal > > connection > > rather than creating additional connections. > > How would you resolve it generically enough in this context? > > Doron, > > I believe your approach a bit different, UX folks seeking for a > convenient > way of communicating with ovirt public api, e.g closing api<->GUI > gap, and > theirs alternatives where native HTTP layer or Java-SDK based > framework, > while what you need is in-process channel to communicate with the > engine itself, > > i understanding your will of using stable api for this (RESTapi), > but > not > sure that doing this via JavaSDK is a good way to go simply because > SDK is > designed to operate in a client-space, while what you need is a > server-space > bridge for that. > Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well.

> > > >> 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org >> Sent: Thursday, February 21, 2013 6:54:59 PM >> Subject: Re: [Engine-devel] REST API calls from >> >> >> >> ----- Original Message ----- >>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >>> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org >>> Sent: Wednesday, February 20, 2013 2:56:59 PM >>> Subject: Re: [Engine-devel] REST API calls from >>> >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>> To: "Libor Spevak" <lspevak(a)redhat.com&gt; >>>>> Cc: engine-devel(a)ovirt.org, arch(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? >>>>> >>>>> [1] http[s]://server[:port]/api?schema >>>>> [2] http[s]://server[:port]/api?rsdl >>>>> >>>> >>>> Although started as a UI request, there are other needs who wish >>>> to use API calls with a different transport. For example a >>>> backend >>>> hook which gets a REST entry point it can use to fetch for >>>> additional >>>> data, or perform actions. In this case I'd expect an internal >>>> connection >>>> rather than creating additional connections. >>>> How would you resolve it generically enough in this context? >>> >>> Doron, >>> >>> I believe your approach a bit different, UX folks seeking for a >>> convenient >>> way of communicating with ovirt public api, e.g closing api<->GUI >>> gap, and >>> theirs alternatives where native HTTP layer or Java-SDK based >>> framework, >>> while what you need is in-process channel to communicate with the >>> engine itself, >>> >>> i understanding your will of using stable api for this (RESTapi), >>> but >>> not >>> sure that doing this via JavaSDK is a good way to go simply >>> because >>> SDK is >>> designed to operate in a client-space, while what you need is a >>> server-space >>> bridge for that. >>> >> >> Michael, true but... >> Thinking about it differently both UI and hooks needs a client. >> The underlying protocols should be abstracted. This is something >> which will serve other functions as well. >> > > I'm not sure we would need a new abstraction here. > Both UI plugins and engine plugins need some API to do basic > operations, and have access to different properties in the engine. +1, that's exactly what i've suggested to begin with.

> In the UI plguins implementation, we gave this API, and in addition > created a REST session to be used in order to do more > sophisticated operations. > I think we should probably do the same for engine plugins, > giving the basic API, and giving a REST session for more advanced > operations. > The engine plugin may also have another 3rd party application it > interacts with, and it would be able to share this session with > it, > allowing it to perform different operations on the engine. It would > obviously be easy to do that using the Java SDK in the engine > side, > without creating a new layer of abstraction. true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do is saving round-trip of engine->sdk->api->engine by enabling extra layer in sdk that will work not via HTTP, but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are: 1. working with java-sdk via JNI (walking out from container to client application - sdk) 2. hacking RESTeasy by: 2.1 working with underlying (not public/backward compatible) interfaces & using JNI as well 2.2 most likely maintaining code working with RESTeasy on every new (RESTeasy) release by reverse engineering new changes/behaviour of this framework 2.3 making assumptions on code invocations to emulate GET/POST/PUT/DELETE HTTP calls 2.4 still having round-trip engine->sdk->RESTeasy->engine therefore i think that having own private API in engine for that is a much better solution. > I assume the 3rd party application will use either the Java SDK, or > another one, according the platform it is built upon, and in the > "worst case", will interact directly with the API. > > >>>> >>>>> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org Sent: Sunday, February 24, 2013 3:01:19 PM Subject: Re: [Engine-devel] REST API calls from ----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > To: "Michael Pasternak" <mpastern(a)redhat.com&gt; > Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org, > arch(a)ovirt.org > Sent: Sunday, February 24, 2013 1:20:12 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > > Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > Sent: Sunday, February 24, 2013 9:47:28 AM > > Subject: Re: [Engine-devel] REST API calls from > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > >> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > >> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > >> Subject: Re: [Engine-devel] REST API calls from > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > >>> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > >>> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > >>> Subject: Re: [Engine-devel] REST API calls from > > >>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > >>>>> To: "Libor Spevak" <lspevak(a)redhat.com&gt; > > >>>>> Cc: engine-devel(a)ovirt.org, arch(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? > > >>>>> > > >>>>> [1] http[s]://server[:port]/api?schema > > >>>>> [2] http[s]://server[:port]/api?rsdl > > >>>>> > > >>>> > > >>>> Although started as a UI request, there are other needs who > > >>>> wish > > >>>> to use API calls with a different transport. For example a > > >>>> backend > > >>>> hook which gets a REST entry point it can use to fetch for > > >>>> additional > > >>>> data, or perform actions. In this case I'd expect an > > >>>> internal > > >>>> connection > > >>>> rather than creating additional connections. > > >>>> How would you resolve it generically enough in this context? > > >>> > > >>> Doron, > > >>> > > >>> I believe your approach a bit different, UX folks seeking for > > >>> a > > >>> convenient > > >>> way of communicating with ovirt public api, e.g closing > > >>> api<->GUI > > >>> gap, and > > >>> theirs alternatives where native HTTP layer or Java-SDK based > > >>> framework, > > >>> while what you need is in-process channel to communicate with > > >>> the > > >>> engine itself, > > >>> > > >>> i understanding your will of using stable api for this > > >>> (RESTapi), > > >>> but > > >>> not > > >>> sure that doing this via JavaSDK is a good way to go simply > > >>> because > > >>> SDK is > > >>> designed to operate in a client-space, while what you need is > > >>> a > > >>> server-space > > >>> bridge for that. > > >>> > > >> > > >> Michael, true but... > > >> Thinking about it differently both UI and hooks needs a > > >> client. > > >> The underlying protocols should be abstracted. This is > > >> something > > >> which will serve other functions as well. > > >> > > > > > > I'm not sure we would need a new abstraction here. > > > Both UI plugins and engine plugins need some API to do basic > > > operations, and have access to different properties in the > > > engine. > > > > +1, that's exactly what i've suggested to begin with. > > > > The only issue is that UI plugins and engine plugins shave > different > expectations > from performance point of view. If UI is willing to wait for a > refresh that may > take too long for engine plugins, which would prefer to get the > information as > soon as possible without going into various communication layers > which are not > always needed. So again- a simple solution which enables transports > layers to > be replaced may serve more than one functionality in a better way. > Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit. (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request).

> > > In the UI plguins implementation, we gave this API, and in > > > addition > > > created a REST session to be used in order to do more > > > sophisticated operations. > > > I think we should probably do the same for engine plugins, > > > giving the basic API, and giving a REST session for more > > > advanced > > > operations. > > > The engine plugin may also have another 3rd party application > > > it > > > interacts with, and it would be able to share this session with > > > it, > > > allowing it to perform different operations on the engine. It > > > would > > > obviously be easy to do that using the Java SDK in the engine > > > side, > > > without creating a new layer of abstraction. > > > > true, but the thing is that java-sdk designed to work with > > rest-api, > > and what Doron is trying to do > > is saving round-trip of engine->sdk->api->engine by enabling > > extra > > layer in sdk that will work not via HTTP, > > but natively with RESTeasy (REST framework we using in api), the > > disadvantages of such design are: > > > > 1. working with java-sdk via JNI (walking out from container to > > client application - sdk) > > 2. hacking RESTeasy by: > > 2.1 working with underlying (not public/backward compatible) > > interfaces & using JNI as well > > 2.2 most likely maintaining code working with RESTeasy on > > every > > new (RESTeasy) release by reverse > > engineering new changes/behaviour of this framework > > 2.3 making assumptions on code invocations to emulate > > GET/POST/PUT/DELETE HTTP calls > > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > > > therefore i think that having own private API in engine for that > > is > > a > > much better solution. > > > > > I assume the 3rd party application will use either the Java > > > SDK, > > > or > > > another one, according the platform it is built upon, and in > > > the > > > "worst case", will interact directly with the API. > > > > > > > > >>>> > > >>>>> 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 > > >>>>>>

From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org Sent: Sunday, February 24, 2013 11:56:49 PM Subject: Re: [Engine-devel] REST API calls from ----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > Sent: Sunday, February 24, 2013 3:55:28 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > Sent: Sunday, February 24, 2013 3:01:19 PM > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > ----- Original Message ----- > > > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > > To: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > > Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org, > > > arch(a)ovirt.org > > > Sent: Sunday, February 24, 2013 1:20:12 PM > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > > > To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > > > > Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > > > Sent: Sunday, February 24, 2013 9:47:28 AM > > > > Subject: Re: [Engine-devel] REST API calls from > > > > > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > > > >> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > > > >> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > > > >> Subject: Re: [Engine-devel] REST API calls from > > > > >> > > > > >> > > > > >> > > > > >> ----- Original Message ----- > > > > >>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > > > >>> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > > > >>> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org > > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > > > >>> Subject: Re: [Engine-devel] REST API calls from > > > > >>> > > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > > >>>> > > > > >>>> > > > > >>>> ----- Original Message ----- > > > > >>>>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > > > >>>>> To: "Libor Spevak" <lspevak(a)redhat.com&gt; > > > > >>>>> Cc: engine-devel(a)ovirt.org, arch(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? > > > > >>>>> > > > > >>>>> [1] http[s]://server[:port]/api?schema > > > > >>>>> [2] http[s]://server[:port]/api?rsdl > > > > >>>>> > > > > >>>> > > > > >>>> Although started as a UI request, there are other needs > > > > >>>> who > > > > >>>> wish > > > > >>>> to use API calls with a different transport. For example > > > > >>>> a > > > > >>>> backend > > > > >>>> hook which gets a REST entry point it can use to fetch > > > > >>>> for > > > > >>>> additional > > > > >>>> data, or perform actions. In this case I'd expect an > > > > >>>> internal > > > > >>>> connection > > > > >>>> rather than creating additional connections. > > > > >>>> How would you resolve it generically enough in this > > > > >>>> context? > > > > >>> > > > > >>> Doron, > > > > >>> > > > > >>> I believe your approach a bit different, UX folks seeking > > > > >>> for > > > > >>> a > > > > >>> convenient > > > > >>> way of communicating with ovirt public api, e.g closing > > > > >>> api<->GUI > > > > >>> gap, and > > > > >>> theirs alternatives where native HTTP layer or Java-SDK > > > > >>> based > > > > >>> framework, > > > > >>> while what you need is in-process channel to communicate > > > > >>> with > > > > >>> the > > > > >>> engine itself, > > > > >>> > > > > >>> i understanding your will of using stable api for this > > > > >>> (RESTapi), > > > > >>> but > > > > >>> not > > > > >>> sure that doing this via JavaSDK is a good way to go > > > > >>> simply > > > > >>> because > > > > >>> SDK is > > > > >>> designed to operate in a client-space, while what you > > > > >>> need > > > > >>> is > > > > >>> a > > > > >>> server-space > > > > >>> bridge for that. > > > > >>> > > > > >> > > > > >> Michael, true but... > > > > >> Thinking about it differently both UI and hooks needs a > > > > >> client. > > > > >> The underlying protocols should be abstracted. This is > > > > >> something > > > > >> which will serve other functions as well. > > > > >> > > > > > > > > > > I'm not sure we would need a new abstraction here. > > > > > Both UI plugins and engine plugins need some API to do > > > > > basic > > > > > operations, and have access to different properties in the > > > > > engine. > > > > > > > > +1, that's exactly what i've suggested to begin with. > > > > > > > > > > The only issue is that UI plugins and engine plugins shave > > > different > > > expectations > > > from performance point of view. If UI is willing to wait for a > > > refresh that may > > > take too long for engine plugins, which would prefer to get the > > > information as > > > soon as possible without going into various communication > > > layers > > > which are not > > > always needed. So again- a simple solution which enables > > > transports > > > layers to > > > be replaced may serve more than one functionality in a better > > > way. > > > > > > > Let's start with the simple solution. We don't know yet who will > > the > > plugins, how would they be used, and whether using the SDK will > > be > > a > > bottleneck of any kind. If the proposed solution is to support > > different transport layers while still using the SDK, then it is > > an > > extension we can always do in the future, if we find it of high > > benefit. > > (btw, regardless of that, the API/SDK is now faster than in the > > past, > > as we support REST sessions, which removes the need to > > re-authenticate upon each API request). > > > > Oved, we have pretty good idea on how it will be used and what will > create performance hits. Otherwise we wouldn't have had this > thread. > If so, it would be nice if you share this information on the thread as well... some use-cases, some statistics you may have on the current performance, and on the performance requirements, and etc. I'm not saying that you're wrong... just saying I wasn't convinced it is really necessary. Thank you, Oved

> > > > > In the UI plguins implementation, we gave this API, and in > > > > > addition > > > > > created a REST session to be used in order to do more > > > > > sophisticated operations. > > > > > I think we should probably do the same for engine plugins, > > > > > giving the basic API, and giving a REST session for more > > > > > advanced > > > > > operations. > > > > > The engine plugin may also have another 3rd party > > > > > application > > > > > it > > > > > interacts with, and it would be able to share this session > > > > > with > > > > > it, > > > > > allowing it to perform different operations on the engine. > > > > > It > > > > > would > > > > > obviously be easy to do that using the Java SDK in the > > > > > engine > > > > > side, > > > > > without creating a new layer of abstraction. > > > > > > > > true, but the thing is that java-sdk designed to work with > > > > rest-api, > > > > and what Doron is trying to do > > > > is saving round-trip of engine->sdk->api->engine by enabling > > > > extra > > > > layer in sdk that will work not via HTTP, > > > > but natively with RESTeasy (REST framework we using in api), > > > > the > > > > disadvantages of such design are: > > > > > > > > 1. working with java-sdk via JNI (walking out from container > > > > to > > > > client application - sdk) > > > > 2. hacking RESTeasy by: > > > > 2.1 working with underlying (not public/backward > > > > compatible) > > > > interfaces & using JNI as well > > > > 2.2 most likely maintaining code working with RESTeasy on > > > > every > > > > new (RESTeasy) release by reverse > > > > engineering new changes/behaviour of this framework > > > > 2.3 making assumptions on code invocations to emulate > > > > GET/POST/PUT/DELETE HTTP calls > > > > 2.4 still having round-trip engine->sdk->RESTeasy->engine > > > > > > > > therefore i think that having own private API in engine for > > > > that > > > > is > > > > a > > > > much better solution. > > > > > > > > > I assume the 3rd party application will use either the Java > > > > > SDK, > > > > > or > > > > > another one, according the platform it is built upon, and > > > > > in > > > > > the > > > > > "worst case", will interact directly with the API. > > > > > > > > > > > > > > >>>> > > > > >>>>> 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org Sent: Monday, February 25, 2013 12:33:01 PM Subject: Re: [Engine-devel] REST API calls from On 02/24/2013 03:01 PM, Oved Ourfalli wrote: > > ----- Original Message ----- >> > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >> > To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >> > Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org, >> > arch(a)ovirt.org >> > Sent: Sunday, February 24, 2013 1:20:12 PM >> > Subject: Re: [Engine-devel] REST API calls from >> > >> > >> > >> > ----- Original Message ----- >>> > > From: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>> > > To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; >>> > > Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org >>> > > Sent: Sunday, February 24, 2013 9:47:28 AM >>> > > Subject: Re: [Engine-devel] REST API calls from >>> > > >>> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: >>>> > > > >>>> > > > >>>> > > > ----- Original Message ----- >>>>> > > >> From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >>>>> > > >> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>> > > >> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org >>>>> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM >>>>> > > >> Subject: Re: [Engine-devel] REST API calls from >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> ----- Original Message ----- >>>>>> > > >>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>>> > > >>> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >>>>>> > > >>> Cc: engine-devel(a)ovirt.org, arch(a)ovirt.org >>>>>> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM >>>>>> > > >>> Subject: Re: [Engine-devel] REST API calls from >>>>>> > > >>> >>>>>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: >>>>>>> > > >>>> >>>>>>> > > >>>> >>>>>>> > > >>>> ----- Original Message ----- >>>>>>>> > > >>>>> From: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>>>>> > > >>>>> To: "Libor Spevak" <lspevak(a)redhat.com&gt; >>>>>>>> > > >>>>> Cc: engine-devel(a)ovirt.org, arch(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? >>>>>>>> > > >>>>> >>>>>>>> > > >>>>> [1] http[s]://server[:port]/api?schema >>>>>>>> > > >>>>> [2] http[s]://server[:port]/api?rsdl >>>>>>>> > > >>>>> >>>>>>> > > >>>> >>>>>>> > > >>>> Although started as a UI request, there are other >>>>>>> > > >>>> needs who >>>>>>> > > >>>> wish >>>>>>> > > >>>> to use API calls with a different transport. For >>>>>>> > > >>>> example a >>>>>>> > > >>>> backend >>>>>>> > > >>>> hook which gets a REST entry point it can use to >>>>>>> > > >>>> fetch for >>>>>>> > > >>>> additional >>>>>>> > > >>>> data, or perform actions. In this case I'd expect an >>>>>>> > > >>>> internal >>>>>>> > > >>>> connection >>>>>>> > > >>>> rather than creating additional connections. >>>>>>> > > >>>> How would you resolve it generically enough in this >>>>>>> > > >>>> context? >>>>>> > > >>> >>>>>> > > >>> Doron, >>>>>> > > >>> >>>>>> > > >>> I believe your approach a bit different, UX folks >>>>>> > > >>> seeking for a >>>>>> > > >>> convenient >>>>>> > > >>> way of communicating with ovirt public api, e.g >>>>>> > > >>> closing >>>>>> > > >>> api<->GUI >>>>>> > > >>> gap, and >>>>>> > > >>> theirs alternatives where native HTTP layer or >>>>>> > > >>> Java-SDK based >>>>>> > > >>> framework, >>>>>> > > >>> while what you need is in-process channel to >>>>>> > > >>> communicate with >>>>>> > > >>> the >>>>>> > > >>> engine itself, >>>>>> > > >>> >>>>>> > > >>> i understanding your will of using stable api for this >>>>>> > > >>> (RESTapi), >>>>>> > > >>> but >>>>>> > > >>> not >>>>>> > > >>> sure that doing this via JavaSDK is a good way to go >>>>>> > > >>> simply >>>>>> > > >>> because >>>>>> > > >>> SDK is >>>>>> > > >>> designed to operate in a client-space, while what you >>>>>> > > >>> need is a >>>>>> > > >>> server-space >>>>>> > > >>> bridge for that. >>>>>> > > >>> >>>>> > > >> >>>>> > > >> Michael, true but... >>>>> > > >> Thinking about it differently both UI and hooks needs a >>>>> > > >> client. >>>>> > > >> The underlying protocols should be abstracted. This is >>>>> > > >> something >>>>> > > >> which will serve other functions as well. >>>>> > > >> >>>> > > > >>>> > > > I'm not sure we would need a new abstraction here. >>>> > > > Both UI plugins and engine plugins need some API to do >>>> > > > basic >>>> > > > operations, and have access to different properties in the >>>> > > > engine. >>> > > >>> > > +1, that's exactly what i've suggested to begin with. >>> > > >> > >> > The only issue is that UI plugins and engine plugins shave >> > different >> > expectations >> > from performance point of view. If UI is willing to wait for a >> > refresh that may >> > take too long for engine plugins, which would prefer to get the >> > information as >> > soon as possible without going into various communication layers >> > which are not >> > always needed. So again- a simple solution which enables >> > transports >> > layers to >> > be replaced may serve more than one functionality in a better >> > way. >> > > Let's start with the simple solution. We don't know yet who will > the plugins, how would they be used, and whether using the SDK > will be a bottleneck of any kind. If the proposed solution is to > support different transport layers while still using the SDK, then > it is an extension we can always do in the future, if we find it > of high benefit. > (btw, regardless of that, the API/SDK is now faster than in the > past, as we support REST sessions, which removes the need to > re-authenticate upon each API request). > true, but the real bottleneck is sending XML bulks over the wire + bi-directional marshalling X 2 (engine<->api + api<->xml).

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

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Libor Spevak" <lspevak(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Daniel Erez" <derez(a)redhat.com&gt;, "Gilad Chaplik" <gchaplik(a)redhat.com&gt;, "Einav Cohen" <ecohen(a)redhat.com&gt;, arch(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?

[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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D

From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; To: "Daniel Erez" <derez(a)redhat.com&gt; Cc: arch(a)ovirt.org, engine-devel(a)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.

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

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

Vojtech ----- Original Message ----- From: "Daniel Erez" <derez(a)redhat.com&gt; To: "Michael Pasternak" <mpastern(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Einav Cohen" <ecohen(a)redhat.com&gt;, arch(a)ovirt.org, "Libor Spevak" <lspevak(a)redhat.com&gt;, "Vojtech Szocs" <vszocs(a)redhat.com&gt; 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(a)redhat.com&gt; > To: "Libor Spevak" <lspevak(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, "Daniel Erez" <derez(a)redhat.com&gt;, > "Gilad Chaplik" <gchaplik(a)redhat.com&gt;, "Einav Cohen" > <ecohen(a)redhat.com&gt;, arch(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(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Kanagaraj Mayilsamy" <kmayilsa(a)redhat.com&gt; Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, engine-devel(a)ovirt.org, arch(a)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(a)redhat.com&gt; >> To: "Daniel Erez" <derez(a)redhat.com&gt; >> Cc: arch(a)ovirt.org, engine-devel(a)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" <derez(a)redhat.com&gt; >> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >> Cc: engine-devel(a)ovirt.org, "Einav Cohen" <ecohen(a)redhat.com&gt;, >> arch(a)ovirt.org, "Libor Spevak" <lspevak(a)redhat.com&gt;, "Vojtech >> Szocs" >> <vszocs(a)redhat.com&gt; >> 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(a)redhat.com&gt; >>> To: "Libor Spevak" <lspevak(a)redhat.com&gt; >>> Cc: engine-devel(a)ovirt.org, "Daniel Erez" <derez(a)redhat.com&gt;, >>> "Gilad Chaplik" <gchaplik(a)redhat.com&gt;, "Einav Cohen" >>> <ecohen(a)redhat.com&gt;, arch(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(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D

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

if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does),

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

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

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

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. > 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). > 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. Vojtech ----- Original Message ----- From: "Daniel Erez" <derez(a)redhat.com&gt; To: "Michael Pasternak" <mpastern(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Einav Cohen" <ecohen(a)redhat.com&gt;, arch(a)ovirt.org, "Libor Spevak" <lspevak(a)redhat.com&gt;, "Vojtech Szocs" <vszocs(a)redhat.com&gt; 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(a)redhat.com&gt; > To: "Libor Spevak" <lspevak(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, "Daniel Erez" <derez(a)redhat.com&gt;, "Gilad Chaplik" <gchaplik(a)redhat.com&gt;, "Einav Cohen" > <ecohen(a)redhat.com&gt;, arch(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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D