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