[Engine-devel] REST API calls from

Oved Ourfalli ovedo at redhat.com
Sun Feb 24 21:56:49 UTC 2013 


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

More information about the Arch mailing list