[Engine-devel] REST API calls from

Doron Fediuck dfediuck at redhat.com
Thu Feb 21 16:54:59 UTC 2013



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

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



More information about the Arch mailing list