Re: [Engine-devel] REST API calls from

From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, arch(a)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(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 3:55:28 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- > > From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > Cc: engine-devel(a)ovirt.org, arch(a)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(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). > > > > 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel