rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: CXF Rest + WS Data Model
Date Wed, 27 Mar 2013 17:59:20 GMT
On Wed, Mar 27, 2013 at 10:42 AM, Erin Noe-Payne
<erin.noe.payne@gmail.com>wrote:

> On Wed, Mar 27, 2013 at 1:16 PM, Matt Franklin <m.ben.franklin@gmail.com
> >wrote:
>
> > On Thu, Mar 21, 2013 at 5:32 PM, Chris Geer <chris@cxtsoftware.com>
> 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?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message