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