Re: [Engine-devel] REST API calls from

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.

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