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 18:32:00 GMT
On Wed, Mar 27, 2013 at 11:27 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:

> On Wed, Mar 27, 2013 at 1:59 PM, Chris Geer <chris@cxtsoftware.com> wrote:
> > 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).
>
> 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.
>

I don't understand this comment. How would this cause serious performance
bottlenecks? Having additional services won't cause any problems, and they
should only be called when they are used which would be no more/less than
if it was a single service. I'm ok not doing this, just not sure what would
cause the major performance problems you are referring to.

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

ok

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