Re: [Engine-devel] REST API calls from

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