[Engine-devel] REST API calls from

Mon Feb 25 13:20:09 UTC 2013


----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org, arch at 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 at redhat.com>
> >> > To: "Michael Pasternak" <mpastern at redhat.com>
> >> > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org,
> >> > arch at 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 at redhat.com>
> >>> > > To: "Oved Ourfalli" <ovedo at redhat.com>
> >>> > > Cc: engine-devel at ovirt.org, arch at 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 at redhat.com>
> >>>>> > > >> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>> > > >> Cc: engine-devel at ovirt.org, arch at 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 at redhat.com>
> >>>>>> > > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>>> > > >>> Cc: engine-devel at ovirt.org, arch at 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 at redhat.com>
> >>>>>>>> > > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> >>>>>>>> > > >>>>> Cc: engine-devel at ovirt.org, arch at 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).
> 
Here we're in agreement.