rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: [Proposal] REST API interface
Date Tue, 23 Jul 2013 16:14:39 GMT
On Mon, Jul 22, 2013 at 9:04 PM, Erin Noe-Payne <erin.noe.payne@gmail.com>wrote:

> On Mon, Jul 22, 2013 at 11:56 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> > On Mon, Jul 22, 2013 at 12:58 PM, Erin Noe-Payne
> > <erin.noe.payne@gmail.com>wrote:
> >
> >> - Simple solution: All rest response models are flat. We ignore any
> >> nested data, and just have separate endpoints to deliver that data.
> >> I.E. Every model in the org.apache.rave.rest.model package has only
> >> properties of "primitive" types, with no lists, no other classes. That
> >> is NOT currently the case. Then the fields interceptor checks for the
> >> presence of a fields argument. If not present, the object is delivered
> >> as is. If present the argument (a string) is split by comma and only
> >> the matched properties are delivered. The fields qs argument only has
> >> to support comma-delimited list of property names.
> >> Ex: ?fields=name,pageType
> >> //returns a page or pages with only name and pageType properties
> >>
> >
> > I like the simple solution. I think the CRUD part of the API should be as
> > flat as possible like Erin suggested and we have "special" end points to
> > get back hierarchical data when needed, i.e. page rendering.
> >
>
> Just to make sure we are on the same page, my proposal is that in both
> cases a get request without any special query string will return only
> flat data. The difference is that in the second case the fields query
> parameter will support a syntax that CAN deliver nested data in a
> single request.
>

That confuses me. I thought the whole point of the "special" end point was
to handle things like page rendering in one query which would require
hierarchical data every time. Why force the use of query string params to
get that?

>
> >>
> >> - Complicated solution: All rest response models include references to
> >> their nested data. This is the currently the case, and can be seen in
> >> org.apache.rave.rest.model.Page. The fields interceptor checks for
> >> presence of fields qs argument. If not present it strips all nested
> >> data from the models and only returns properties. If it is present, it
> >> parses the argument and updates the data. The fields argument needs to
> >> support a more complicated syntax that allows the requesting of nested
> >> data. I would copy the syntax of facebook's graph search api, which
> >> has a pretty readable solution. You allow for .fields and .limit on
> >> fields, which can be nested.
> >> Ex:
> >>
> ?fields=name,pageType,regions.limit(2).fields(regionWidgets.fields(widgetId,locked))
> >> //returns a page or pages with name and pageType properties, nested
> >> list of regions (max of 2) with nested list of regionWidgets with only
> >> properties of widgetId and locked
> >>
> >> In all cases, id should always be returned.
> >> I think the algorithm in the simple solution is easy.
> >> In a sense the algorithm in the second should be simple, because the
> >> service layer is already getting all the nested data, and you are just
> >> stripping it off. Not sure what the performance implications of that
> >> are though.
> >>
> >> On Mon, Jul 22, 2013 at 3:40 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> >> > On Mon, Jul 22, 2013 at 12:07 PM, Erin Noe-Payne
> >> > <erin.noe.payne@gmail.com>wrote:
> >> >
> >> >> Going back to the discussion on field selection - I am currently
> going
> >> >> through the exercise of writing out the Resource interfaces to define
> >> >> our endpoints.  There is a set of generic query string parameters
> that
> >> >> we wish to support on all or many of the endpoints - fields (any get
> >> >> request), limit / offset (any get request that returns a list).
> >> >>
> >> >> Rather than writing each endpoint to accept QueryParam()'s and repeat
> >> >> the appropriate logic, I assume we would want to take advantage of
> cxf
> >> >> interceptors [1] to intelligently and generically handle those qs
> >> >> arguments?
> >> >>
> >> >
> >> > I like the concept but I'm not sure how we generically filter,
> especially
> >> > with nested data. I'd love to see it work that way though.
> Interceptors
> >> are
> >> > pretty easy to use, it's the filter algorithm I haven't figured out
> yet.
> >> > Thoughts?
> >> >
> >> >>
> >> >> [1] http://cxf.apache.org/docs/interceptors.html
> >> >>
> >> >> On Mon, Jul 22, 2013 at 11:40 AM, Erin Noe-Payne
> >> >> <erin.noe.payne@gmail.com> wrote:
> >> >> > Ok, so the endpoint is now working. Any thoughts about the
> >> >> > JsonResponseWrapper approach? Does that seem like the best way
to
> get
> >> >> > wrapped responses?
> >> >> >
> >> >> > For the next step I would like to start writing out all of the
> >> >> > resource interfaces so that we can begin writing angular $resource
> >> >> > services against them.
> >> >> >
> >> >> > On Sun, Jul 21, 2013 at 8:54 PM, Erin Noe-Payne
> >> >> > <erin.noe.payne@gmail.com> wrote:
> >> >> >> Awesome, thanks Chris. Not sure I would have ever figured
that one
> >> >> out...
> >> >> >>
> >> >> >> On Sun, Jul 21, 2013 at 3:59 PM, Chris Geer <
> chris@cxtsoftware.com>
> >> >> wrote:
> >> >> >>> Erin,
> >> >> >>>
> >> >> >>> I got it working, at least the CXF part. Couple things:
> >> >> >>>
> >> >> >>> 1) In the interface, make sure to annotate the @GET methods
> >> >> >>> 2) In your DefaultRegionWidgetsResource class, remove
the
> @ParamPath
> >> >> >>> attributes from variable signatures. I know Intellij puts
those
> in
> >> >> there
> >> >> >>> but they cause problems. Only the interface should be
annotated.
> >> >> >>>
> >> >> >>> Chris
> >> >> >>>
> >> >> >>>
> >> >> >>> On Sat, Jul 20, 2013 at 2:00 PM, Erin Noe-Payne <
> >> >> erin.noe.payne@gmail.com>wrote:
> >> >> >>>
> >> >> >>>> Review board is not accepting my patch and is not
accepting the
> >> valid
> >> >> >>>> file paths. I have attached the patch as a file to
the review.
> >> >> >>>>
> >> >> >>>> On Sat, Jul 20, 2013 at 4:40 PM, Chris Geer <
> chris@cxtsoftware.com
> >> >
> >> >> wrote:
> >> >> >>>> > Erin, I'm not seeing a patch posted up there.
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> > On Fri, Jul 19, 2013 at 2:27 PM, Erin Noe-Payne
<
> >> >> >>>> erin.noe.payne@gmail.com>wrote:
> >> >> >>>> >
> >> >> >>>> >> I was never able to hit the endpoint as expected.
I've posted
> >> the
> >> >> >>>> >> patch on the review board if anyone can take
a look and offer
> >> >> advice -
> >> >> >>>> >> https://reviews.apache.org/r/12777/.
> >> >> >>>> >>
> >> >> >>>> >> Thanks
> >> >> >>>> >>
> >> >> >>>> >> On Fri, Jul 19, 2013 at 2:41 PM, Chris Geer
<
> >> chris@cxtsoftware.com
> >> >> >
> >> >> >>>> wrote:
> >> >> >>>> >> > On Friday, July 19, 2013, Erin Noe-Payne
wrote:
> >> >> >>>> >> >
> >> >> >>>> >> >> On Fri, Jul 19, 2013 at 1:24 PM,
Chris Geer <
> >> >> chris@cxtsoftware.com
> >> >> >>>> >> <javascript:;>>
> >> >> >>>> >> >> wrote:
> >> >> >>>> >> >> > In the xml file you need to
create the bean, then
> reference
> >> >> it in
> >> >> >>>> the
> >> >> >>>> >> >> > server element near the top.
Other than that...no, that
> >> >> should be
> >> >> >>>> >> all. I
> >> >> >>>> >> >> > assume you set the Path attribute
on the resource.
> >> >> >>>> >> >> >
> >> >> >>>> >> >> I did. I'm also messing around with
the service injection,
> >> >> which may
> >> >> >>>> >> >> be the issue. Haven't gotten it
to work yet though.
> >> >> >>>> >> >>
> >> >> >>>> >> >> > I thought we were going to
do
> >> >> >>>> >> pages/<id>/regions/<id>/regionwidgets/<id>
> >> >> >>>> >> >> > since it makes no sense to
manage a region widget
> outside a
> >> >> region
> >> >> >>>> >> >> outside
> >> >> >>>> >> >> > a page?
> >> >> >>>> >> >>  Possibly. Right now I'm just trying
to do a proof of
> concept
> >> >> with
> >> >> >>>> the
> >> >> >>>> >> >> wrapped json object so I picked
something simple with the
> >> >> service and
> >> >> >>>> >> >> rest models already in place.
> >> >> >>>> >> >>
> >> >> >>>> >> >> In general though I don't see any
value to dealing with
> >> region
> >> >> >>>> widgets
> >> >> >>>> >> >> as a nested resource (pages/:id/regions/:id...)
over just
> >> >> dealing
> >> >> >>>> with
> >> >> >>>> >> >> them directly. It's just adding
weight to the pages
> >> controller,
> >> >> >>>> rather
> >> >> >>>> >> >> than breaking them up and dealing
with resource concerns
> >> >> separately.
> >> >> >>>> >> >>
> >> >> >>>> >> >> I get what you're saying about regions
and regionwidgets
> only
> >> >> making
> >> >> >>>> >> >> sense in the context of a page,
but you could say the same
> >> >> thing for
> >> >> >>>> >> >> any 1-many associated resource.
Both entities are always
> >> >> uniquely
> >> >> >>>> >> >> identified, so why not deal with
them individually? I see
> an
> >> >> upside
> >> >> >>>> of
> >> >> >>>> >> >> simpler code, consistent api endpoints,
and I see no
> >> downside.
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> > Honestly, my hope is that someday they
aren't uniquely
> >> >> identified and
> >> >> >>>> are
> >> >> >>>> >> > really sun objects unlike JPA today.
But that is a longer
> >> >> >>>> conversation.
> >> >> >>>> >> >
> >> >> >>>> >> >>
> >> >> >>>> >> >> >
> >> >> >>>> >> >> >
> >> >> >>>> >> >> > On Fri, Jul 19, 2013 at 10:16
AM, Erin Noe-Payne
> >> >> >>>> >> >> > <erin.noe.payne@gmail.com>wrote:
> >> >> >>>> >> >> >
> >> >> >>>> >> >> >> I'm trying to register
a new endpoint for
> regionWidgets.
> >> I've
> >> >> >>>> added
> >> >> >>>> >> >> >> the interface and default
implementation, and created /
> >> >> registered
> >> >> >>>> >> the
> >> >> >>>> >> >> >> bean in cxf-applicationContext.xml.
> >> >> >>>> >> >> >>
> >> >> >>>> >> >> >> However, when I hit the
endpoint I get an error:
> >> >> >>>> >> >> >> [INFO] [talledLocalContainer]
WARN :
> >> >> >>>> >> >> >> org.apache.cxf.jaxrs.utils.JAXRSUtils
- No operation
> >> matching
> >> >> >>>> request
> >> >> >>>> >> >> >> path "/portal/api/rest/regionWidgets/1"
is found,
> Relative
> >> >> Path:
> >> >> >>>> /1,
> >> >> >>>> >> >> >> HTTP Method: GET, ContentType:
*/*, Accept:
> >> >> >>>> >> >> >>
> >> >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,.
> >> >> >>>> >> >> >> Please enable FINE/TRACE
log level for more details.
> >> >> >>>> >> >> >>
> >> >> >>>> >> >> >> Is there anything else
I need to do in order to create
> and
> >> >> >>>> register a
> >> >> >>>> >> >> >> new endpoint?
> >> >> >>>> >> >> >>
> >> >> >>>> >> >> >> On Tue, Jul 16, 2013 at
11:53 PM, Erin Noe-Payne
> >> >> >>>> >> >> >> <erin.noe.payne@gmail.com>
wrote:
> >> >> >>>> >> >> >> > On Tue, Jul 16, 2013
at 10:24 PM, Chris Geer <
> >> >> >>>> >> chris@cxtsoftware.com>
> >> >> >>>> >> >> >> wrote:
> >> >> >>>> >> >> >> >> On Tue, Jul 16,
2013 at 7:04 PM, Erin Noe-Payne <
> >> >> >>>> >> >> >> erin.noe.payne@gmail.com>wrote:
> >> >> >>>> >> >> >> >>
> >> >> >>>> >> >> >> >>> On Tue, Jul
16, 2013 at 9:20 PM, Matt Franklin <
> >> >> >>>> >> >> >> m.ben.franklin@gmail.com>
> >> >> >>>> >> >> >> >>> wrote:
> >> >> >>>> >> >> >> >>> > On Tue,
Jul 16, 2013 at 12:53 PM, Chris Geer <
> >> >> >>>> >> >> chris@cxtsoftware.com>
> >> >> >>>> >> >> >> >>> wrote:
> >> >> >>>> >> >> >> >>> >
> >> >> >>>> >> >> >> >>> >> On
Tue, Jul 16, 2013 at 10:32 AM, Erin Noe-Payne
> >> >> >>>> >> >> >> >>> >> <erin.noe.payne@gmail.com>wrote:
> >> >> >>>> >> >> >> >>> >>
> >> >> >>>> >> >> >> >>> >> >
Any further discussion here? I would like to
> >> start
> >> >> >>>> >> implementing
> >> >> >>>> >> >> >> more
> >> >> >>>> >> >> >> >>> >> >
of the REST APIs, as it is foundational for
> the
> >> >> entire
> >> >> >>>> >> angular
> >> >> >>>> >> >> >> >>> >> >
architecture.
> >> >> >>>> >> >> >> >>> >> >
> >> >> >>>> >> >> >> >>> >> >
My understanding from Matt is that the current
> >> apis
> >> >> in
> >> >> >>>> trunk
> >> >> >>>> >> >> are
> >> >> >>>> >> >> >> >>> >> >
mostly proof of concept - they are not tested
> and
> >> >> much of
> >> >> >>>> >> the
> >> >> >>>> >> >> >> >>> >> >
functionality is just stubbed. Are any of the
> >> rest
> >> >> api
> >> >> >>>> >> >> >> implementations
> >> >> >>>> >> >> >> >>> >> >
in the code base a good working example? Is
> there
> >> >> other
> >> >> >>>> >> >> >> documentation
> >> >> >>>> >> >> >> >>> >> >
we can reference?
> >> >> >>>> >> >> >> >>> >> >
> >> >> >>>> >> >> >> >>> >>
> >> >> >>>> >> >> >> >>> >> I've
been working on the People resource as a
> >> >> "reference"
> >> >> >>>> of
> >> >> >>>> >> how
> >> >> >>>> >> >> I'd
> >> >> >>>> >> >> >> >>> like
> >> >> >>>> >> >> >> >>> >> to
see them done but it's still a work in
> >> progress. I
> >> >> need
> >> >> >>>> to
> >> >> >>>> >> go
> >> >> >>>> >> >> >> back
> >> >> >>>> >> >> >> >>> and
> >> >> >>>> >> >> >> >>> >> pull
out the JSONView stuff and reimplement the
> >> >> "fields"
> >> >> >>>> >> concept.
> >> >> >>>> >> >> >> >>> Couple of
> >> >> >>>> >> >> >> >>> >> notes:
> >> >> >>>> >> >> >> >>> >>
> >> >> >>>> >> >> >> >>> >> 
- Object representations should be as flat as
> >> >> possible
> >> >> >>>> >> >> >> >>> >> and
separate requests should be made to nested
> >> >> resources to
> >> >> >>>> >> get
> >> >> >>>> >> >> >> nested
> >> >> >>>> >> >> >> >>> >> details
(i.e. if you have regions and
> >> >> >>>> regions/1/regionwidgets,
> >> >> >>>> >> >> the
> >> >> >>>> >> >> >> >>> regions
> >> >> >>>> >> >> >> >>> >> representation
should not contain an array of
> >> >> >>>> regionwidgets)
> >> >> >>>> >> >> >> >>> >>
> >> >> >>>> >> >> >> >>> >
> >> >> >>>> >> >> >> >>> > I am
concerned about the round trips to support
> this
> >> >> when
> >> >> >>>> >> >> rendering
> >> >> >>>> >> >> >> the
> >> >> >>>> >> >> >> >>> > page.
 With any page that has a sufficient
> number of
> >> >> >>>> gadgets,
> >> >> >>>> >> >> adding
> >> >> >>>> >> >> >> to
> >> >> >>>> >> >> >> >>> the
> >> >> >>>> >> >> >> >>> > number
of requests becomes problematic.
> >> >> >>>> >> >> >> >>> >
> >> >> >>>> >> >> >> >>>
> >> >> >>>> >> >> >> >>> I see that
rule applying to the "standard" rest
> >> >> endpoints for
> >> >> >>>> >> crud
> >> >> >>>> >> >> >> >>> operations
on resources. We
> >> >> >>>> >>
> >> >> >>>>
> >> >>
> >>
>

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