On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
>
>
> ----- Original Message -----
>> From: "Doron Fediuck" <dfedi...@redhat.com>
>> To: "Michael Pasternak" <mpast...@redhat.com>
>> Cc: engine-devel@ovirt.org, 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" <mpast...@redhat.com>
>>> To: "Doron Fediuck" <dfedi...@redhat.com>
>>> Cc: engine-devel@ovirt.org, 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" <mpast...@redhat.com>
>>>>> To: "Libor Spevak" <lspe...@redhat.com>
>>>>> Cc: engine-devel@ovirt.org, 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.
> 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@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
