On 02/14/2013 11:20 AM, Doron Fediuck wrote:
----- Original Message -----
> From: "Michael Pasternak" <mpastern(a)redhat.com>
> To: "Libor Spevak" <lspevak(a)redhat.com>
> 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.
> 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
>
>
> --
>
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Arch mailing list
> Arch(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/arch
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D