On Wed, Mar 27, 2013 at 1:59 PM, Chris Geer <[email protected]> wrote: > On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne > <[email protected]>wrote: > >> On Wed, Mar 27, 2013 at 1:16 PM, Matt Franklin <[email protected] >> >wrote: >> >> > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <[email protected]> >> wrote: >> > > I've done a first cut at adding some new CXF based REST web services >> > which >> > > use a different data model >> > >> > As part of RAVE-924, I have created a new page model for web. As I >> > was building it, it occurred to me that there are a couple of >> > different ways we will want/need to use the REST interface for Page: >> > >> > 1) As an export mechanism >> > 2) As an OMDL export mechanism >> > 3) As an entry point for applications who want to render widgets >> > (including the portal) >> > >> > IMO, #1 is straight forward. For number 2, I was thinking that it >> > would be better if there was an OMDL mime type so the logical mapping >> > remains the same (/api/pages/{id}) as in the regular export. What >> > does everyone think about using application/vnd.omdl+xml? >> > >> >> +1 here, I think mime type is the right approach. I have no opinion on the >> actual label of the mime type - that looks fine. >> > > +1 > >> >> >> > >> > The hard part is how to deal with rendering. For this "mode" we will >> > need to export the Wookie iFrame URL (which is per-user), the >> > openSocial security token and the OpenSocial metadata. These require >> > a User to be authenticated and should not be exposed across things >> > like the OMDL or Page export. What would everyone think about the >> > following url for this case?: /api/pages/{id}?render=true >> > >> >> My gut reaction is that I dont like having a query string parameter to >> dictate this. It seems like it would be better for the endpoint to be >> context aware somehow. Possibly check the request and deliver the >> render-ready data set if its coming from an authenticated rave user? I need >> to think about that a bit more... >> > > I agree with Erin, not a fan of the query string. I'd rather see > /api/pages/{id}/rendered or something similar. > > Is the intent to return the wookie and OS stuff in the same response? I'm > not a fan of that, especially considering some people won't have wookie > installed at all (or OS).
The approach I was going to take is to inject all the providers in the current context into a service and when the render condition is hit, have the provider return an object that extends the 'core' RegionWidget with its own properties. This way, there is no coupling to any specific provider. You would be able to have 0...n providers. >Maybe it makes more sense to have a different web > service for rendering by each provider??? This will end up causing serious performance bottlenecks in an already taxed system. >Otherwise this "core" service has > to know about all the different providers which can be a problem moving > forward. It shouldn't have to know anything about any specific provider at all. > >> >> >> > >> > Since we want to be able to "bootstrap" the client MVC framework with >> > a pre-fetched & serialized version of the "Page" we will also need to >> > do the same translation between what is currently returned from the >> > service layer in both the server MVC and the REST API; which raises >> > the question as to wether or not we just abstract all of that >> > functionality in the service layer and only expose the "web" model >> > from that layer or do we create yet another layer to translate from >> > the current service to the web model? >> > >> >> +0 from me. The work should definitely be happening in some service layer >> and keep the controllers light. Beyond that I'm not sure what will end up >> being cleaner. >> >> >> > >> > Thoughts? >> > >>
