REST API calls from

[Michael Pasternak]

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.

> 
>> 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
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D