rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: CXF Rest + WS Data Model
Date Wed, 27 Mar 2013 21:15:46 GMT
On Wed, Mar 27, 2013 at 4:12 PM, Matt Franklin <m.ben.franklin@gmail.com>wrote:

> On Wed, Mar 27, 2013 at 3:35 PM, Chris Geer <chris@cxtsoftware.com> wrote:
> > On Wed, Mar 27, 2013 at 12:25 PM, Erin Noe-Payne
> > <erin.noe.payne@gmail.com>wrote:
> >
> >> On Wed, Mar 27, 2013 at 2:58 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> >>
> >> > On Wed, Mar 27, 2013 at 11:50 AM, Matt Franklin <
> >> m.ben.franklin@gmail.com
> >> > >wrote:
> >> >
> >> > > On Wed, Mar 27, 2013 at 2:32 PM, Chris Geer <chris@cxtsoftware.com>
> >> > wrote:
> >> > > > 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.
> >> >
> >>
> >> I also do not like /api/pages/{id}/rendered.  Url parts should be
> >> semantically representative of resources, not of state or action.
> >>
> >> I'm now thinking...
> >> /api/pages/0 - this is a representation of the generic page for export
> >> /api/users/erin/pages/0 - this is a representation of the page in the
> >> context of user erin, with user-specific data needed for rendering
> >> attached.
> >>
> >
> > I like this in concept but let's play it out. Since all pages are user
> > specific (I think) why would the user link be the rendered? Maybe we
> don't
> > have a /api/pages/??
> >
> > What about something like /api/user/erin/renderedpages/0
>

I don't think pages are user-specific, they just have a relationship to
users. They are still a first class resource in rave and should be
accessible independent of user, so /api/pages should remain imo. There's
nothing wrong with having multiple api routes to arrive at the same
resource.


> We also need to consider how to get the pages by context (IE Portal,
> Profile, etc)


what do you mean by this? Filtering the data set by a property? Portal,
profile or whatever else are just a property of the page.


>
> >
> > That would make it a resource and make more sense.
> >
> > Chris
> >
> >>
> >>
> >> > > >> >
> >> > > >> > 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.
> >> > >
> >> > > I should have been more clear.  As we move away from server-side
> >> > > templating to client-side MVC to deliver the OOTB interface, these
> >> > > services will be used by the framework we have running in the
> browser.
> >> > >  If it has to make AJAX calls for each widget to get the necessary
> >> > > information to render the widget, we are going to end up with a
> bunch
> >> > > of extra AJAX calls in order to initiate rendering of the the
> widgets
> >> > > on a page.  Since widgets are already iFrames and require their own
> >> > > set of round trips to the widget provider, we now end up in a
> >> > > situation we have even more network requests to services.
> >> > >
> >> > > My thought in returning this information as part of the initial page
> >> > > REST call is that we can eliminate the extra round trips to the
> server
> >> > > to get the provider representation of the widget.
> >> > >
> >> >
> >> > That makes sense. The only thing I want to make sure we can do
> >> dynamically
> >> > add (reload) a gadget to a page without re-rendering the whole page.
> >> >
> >>
> >> Absolutely agree. This approach is in line with that goal. The basic
> >> mechanism would be that the page loads with it's initial state
> >> (bootstrapped data we are discussing now). If a user adds a new widget
> then
> >> the client side state is updated and appropriate rendering happens, as
> well
> >> as a post to server to update server side state; no page reload happens.
> >>
> >>
> >> >
> >> > >
> >> > > >
> >> > > >>
> >> > > >> >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