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