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). Maybe it makes more sense to have a different web service for rendering by each provider??? Otherwise this "core" service has to know about all the different providers which can be a problem moving forward. > > > > > > 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? > > >
