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 19:08:50 GMT
Good point...I forgot Rave is using CXF 2.7.x which includes that new
stuff. That would be a better choice, plus it wouldn't tie us to CXF.


On Tue, Jul 23, 2013 at 11:54 AM, Erin Noe-Payne
<erin.noe.payne@gmail.com>wrote:

> Slight update on this journey of discovery - it looks like what we
> actually want to use is not interceptors, but jaxrs filters. See:
> http://cxf.apache.org/docs/jax-rs-filters.html
>
> On Tue, Jul 23, 2013 at 12:56 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> > On Tue, Jul 23, 2013 at 9:55 AM, Erin Noe-Payne <
> erin.noe.payne@gmail.com>wrote:
> >
> >> On Tue, Jul 23, 2013 at 12:14 PM, Chris Geer <chris@cxtsoftware.com>
> >> wrote:
> >> > 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?
> >> >
> >>
> >> I was speaking in reference to the standard endpoints. The
> >> page(s)ForRender endpoint is a special endpoint that serves a specific
> >> client need for a complex nested data set. It will always return
> >> hierarchical data, will probably not support field selection at all.
> >>
> >> The standard endpoints will by default return flat data. They will
> >> support field selection. If we choose to implement the more complex
> >> field selection, then they will allow you to request nested data
> >> through the field selection syntax.
> >>
> >
> > ok
> >
> >>
> >> >>
> >> >> >>
> >> >> >> - 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