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 Mon, 29 Jul 2013 13:59:08 GMT
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.

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