[Engine-devel] REST API calls from

Doron Fediuck dfediuck at redhat.com
Sun Feb 24 13:55:28 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 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.

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

More information about the Arch mailing list