[Engine-devel] REST API calls from

Doron Fediuck dfediuck at redhat.com
Mon Feb 25 13:24:31 UTC 2013 


----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org, arch at 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 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 3:55:28 PM
> > Subject: Re: [Engine-devel] REST API calls from
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Oved Ourfalli" <ovedo at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: engine-devel at ovirt.org, arch at 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 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).
> > > 
> > 
> > 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

Think of intensive calls to an external scheduling 'hook'. We had a few
threads about it in the past, and there's a wiki (being reworked now).
Since you can never anticipate the information that hook will need, we
should allow it to use REST API to fetch the information it needs from
the backend. As Michael already answered opening a client in that hook
will not be the optimal solution if it needs to open TCP connections.

> > > > > > 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

More information about the Arch mailing list