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: [Proposal] REST API interface
Date Wed, 31 Jul 2013 18:19:56 GMT
On Mon, Jul 29, 2013 at 9:59 AM, Erin Noe-Payne
<erin.noe.payne@gmail.com> wrote:
> On Mon, Jul 29, 2013 at 1:54 AM, Chris Geer <chris@cxtsoftware.com> wrote:
>> On Thu, Jul 25, 2013 at 11:12 AM, Erin Noe-Payne
>> <erin.noe.payne@gmail.com>wrote:
>>
>>> I'm not entirely sure how to proceed at the moment. For now I will
>>> start work at the repository layer and try to implement consistent
>>> crud operations to support the REST api.
>>>
>>
>> Erin, on the CXF 2.7 migration page I saw this.
>>
>>
>>    - org.apache.cxf.jaxrs.ext.RequestHandler and
>>    org.apache.cxf.jaxrs.ext.ResponseHandler (use
>>    javax.ws.rs.container.ContainerRequestFilter and
>>    javax.ws.rs.container.ContainerResponseFilter instead).
>>
> Thanks Chris, I'll take a look.
>

It looks like ContainerRequestFilter / ContainerResponseFilter do give
me access to valid request and response context objects that I can act
upon. So these are the interfaces we will want to use for setting up
filters.

Also based on some more reading of CXF docs, it looks to me like we
can use sub-resource locators [1] as an approach for breaking apart
the page / region / regionWidget controllers while still using the
/pages/:id/regions/:id/regionWidgets/:id url paths.

I have submitted a patch on the review board [2] with a partial
implementation (RB is again preventing me from uploading the patch
directly so it is an attachment on the review). Look at the resolution
from PagesResource to RegionsResource. If there are no complaints I am
going to move forward with this approach.

[1] http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Subresourcelocators.
[2] https://reviews.apache.org/r/13119/

>>
>> So, it looks like the docs are a little out of date. The
>> ContainerResponseFilter handler method gets two params, Request Context and
>> Response Context. That might give you what you need. I haven't played with
>> it yet but it's worth a look.
>>
>> Chris
>>
>>
>>
>>> On Wed, Jul 24, 2013 at 1:59 PM, Erin Noe-Payne
>>> <erin.noe.payne@gmail.com> wrote:
>>> > On Wed, Jul 24, 2013 at 1:37 PM, Chris Geer <chris@cxtsoftware.com>
>>> wrote:
>>> >> What about this:
>>> >>
>>> >>
>>> http://cxf.apache.org/docs/jax-rs-filters.html#JAX-RSFilters-OverridingrequestURI%2Cqueryandheaders
>>> >>
>>> >
>>> > This is referring to a RequestHandler, not a ResponseHandler. In the
>>> > request handler the Message object does have correct request uri data,
>>> > etc, but I don't have access to the Response object yet.
>>> >
>>> >> The only thing I don't like about not returning Response objects is it
>>> >> doesn't let the method set HTTP specific stuff. Which just means we need
>>> >> really really good filters. For example, a create should set the
>>> Location
>>> >> HTTP header field with the proper URL to the newly created object.
>>> >>
>>> >
>>> > That's fair. And the controllers could return response objects and
>>> > following filters could just iteratively return
>>> > Response.fromResponse(). But if we take a step back from filters or
>>> > interceptors or whatever implementation approach, here's the problem
>>> > I'm trying to solve:
>>> >
>>> > Taking your Location header example - all requests to get or create an
>>> > entity should have the location header set to the canonical url of the
>>> > resource. Post requests creating a new resource should have a location
>>> > header pointing to the newly created resource. That is universally
>>> > true, and I should be able to write that code generically. I do not
>>> > want to have to set the location header in every controller for every
>>> > resource that handles the @POST method. That seems like it should be
>>> > doable, and filters or interceptors seemed like the way to do it. Now
>>> > I'm not so sure.
>>> >
>>> > So is that a goal worth pursuing, and if yes what is the right approach?
>>> >
>>> >>
>>> >> On Wed, Jul 24, 2013 at 9:21 AM, Erin Noe-Payne <
>>> erin.noe.payne@gmail.com>wrote:
>>> >>
>>> >>> Ok, I'm having trouble setting up filters that are able to access
>>> >>> query string parameters to do pagination. I've submitted a review
>>> >>> request [1] with my work so far (look at pages, categories, and the
>>> >>> filters). My plan was the following workflow -
>>> >>>
>>> >>> - Request is received and processed by the controller. Controller
>>> >>> returns an object <T> or List<T> (Page, Category, etc). For any list
>>> >>> resource it gets all entities, and allows the pagination filter to
>>> >>> subset.
>>> >>> - JsonWrapperResponseFilter process the request and wraps the data
>>> >>> object in the wrapper object
>>> >>> - PaginationResponseFilter checks if the data object is a list. It
>>> >>> retrieves the values of limit and offset QS parameters or sets them to
>>> >>> defaults. It then subsets the data and sets appropriate meta fields in
>>> >>> the json object.
>>> >>>
>>> >>> The issue is that the response handler does not give me access (as far
>>> >>> as I can tell) to the query string values. Which makes me think I'm
>>> >>> missing something, or that this is the wrong way to approach the
>>> >>> problem.  Any help or input is appreciated.
>>> >>>
>>> >>>
>>> >>> [1] https://reviews.apache.org/r/12901/
>>> >>>
>>> >>> On Tue, Jul 23, 2013 at 3:08 PM, Chris Geer <chris@cxtsoftware.com>
>>> wrote:
>>> >>> > 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
View raw message