On Wed, Jul 31, 2013 at 11:19 AM, Erin Noe-Payne <[email protected]>wrote:
> On Mon, Jul 29, 2013 at 9:59 AM, Erin Noe-Payne > <[email protected]> wrote: > > On Mon, Jul 29, 2013 at 1:54 AM, Chris Geer <[email protected]> > wrote: > >> On Thu, Jul 25, 2013 at 11:12 AM, Erin Noe-Payne > >> <[email protected]>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/ Erin, On your RegionWidgetsResource, wouldn't you want the class level path to be @Path("/pages/{pageId}/regions/{regionsId}/regionWidgets") If you have it with just @Path("/pages") it doesn't really nest the regionWidgets under the correct page. > > > >> > >> 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 > >>> <[email protected]> wrote: > >>> > On Wed, Jul 24, 2013 at 1:37 PM, Chris Geer <[email protected]> > >>> 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 < > >>> [email protected]>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 <[email protected] > > > >>> 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 > >>> >>> > <[email protected]>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 < > [email protected] > >>> > > >>> >>> >> wrote: > >>> >>> >> > On Tue, Jul 23, 2013 at 9:55 AM, Erin Noe-Payne < > >>> >>> >> [email protected]>wrote: > >>> >>> >> > > >>> >>> >> >> On Tue, Jul 23, 2013 at 12:14 PM, Chris Geer < > >>> [email protected]> > >>> >>> >> >> wrote: > >>> >>> >> >> > On Mon, Jul 22, 2013 at 9:04 PM, Erin Noe-Payne < > >>> >>> >> >> [email protected]>wrote: > >>> >>> >> >> > > >>> >>> >> >> >> On Mon, Jul 22, 2013 at 11:56 PM, Chris Geer < > >>> >>> [email protected]> > >>> >>> >> >> >> wrote: > >>> >>> >> >> >> > On Mon, Jul 22, 2013 at 12:58 PM, Erin Noe-Payne > >>> >>> >> >> >> > <[email protected]>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 < > >>> >>> >> [email protected]> > >>> >>> >> >> >> wrote: > >>> >>> >> >> >> >> > On Mon, Jul 22, 2013 at 12:07 PM, Erin Noe-Payne > >>> >>> >> >> >> >> > <[email protected]>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 > >>> >>> >> >> >> >> >> <[email protected]> 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 > >>> >>> >> >> >> >> >> > <[email protected]> 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 < > >>> >>> >> >> >> [email protected]> > >>> >>> >> >> >> >> >> 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 > < > >>> >>> >> >> >> >> >> [email protected]>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 < > >>> >>> >> >> >> [email protected] > >>> >>> >> >> >> >> > > >>> >>> >> >> >> >> >> wrote: > >>> >>> >> >> >> >> >> >>>> > Erin, I'm not seeing a patch posted up there. > >>> >>> >> >> >> >> >> >>>> > > >>> >>> >> >> >> >> >> >>>> > > >>> >>> >> >> >> >> >> >>>> > On Fri, Jul 19, 2013 at 2:27 PM, Erin > Noe-Payne < > >>> >>> >> >> >> >> >> >>>> [email protected]>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 > < > >>> >>> >> >> >> >> [email protected] > >>> >>> >> >> >> >> >> > > >>> >>> >> >> >> >> >> >>>> wrote: > >>> >>> >> >> >> >> >> >>>> >> > On Friday, July 19, 2013, Erin Noe-Payne > >>> wrote: > >>> >>> >> >> >> >> >> >>>> >> > > >>> >>> >> >> >> >> >> >>>> >> >> On Fri, Jul 19, 2013 at 1:24 PM, Chris > Geer < > >>> >>> >> >> >> >> >> [email protected] > >>> >>> >> >> >> >> >> >>>> >> <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 > >>> >>> >> >> >> >> >> >>>> >> >> > <[email protected]>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 > >>> >>> >> >> >> >> >> >>>> >> >> >> <[email protected]> wrote: > >>> >>> >> >> >> >> >> >>>> >> >> >> > On Tue, Jul 16, 2013 at 10:24 PM, > Chris > >>> >>> Geer < > >>> >>> >> >> >> >> >> >>>> >> [email protected]> > >>> >>> >> >> >> >> >> >>>> >> >> >> wrote: > >>> >>> >> >> >> >> >> >>>> >> >> >> >> On Tue, Jul 16, 2013 at 7:04 PM, > Erin > >>> >>> >> Noe-Payne < > >>> >>> >> >> >> >> >> >>>> >> >> >> [email protected]>wrote: > >>> >>> >> >> >> >> >> >>>> >> >> >> >> > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> On Tue, Jul 16, 2013 at 9:20 PM, > Matt > >>> >>> >> Franklin < > >>> >>> >> >> >> >> >> >>>> >> >> >> [email protected]> > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> wrote: > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> > On Tue, Jul 16, 2013 at 12:53 > PM, > >>> Chris > >>> >>> >> Geer < > >>> >>> >> >> >> >> >> >>>> >> >> [email protected]> > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> wrote: > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> > > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> >> On Tue, Jul 16, 2013 at 10:32 > AM, > >>> Erin > >>> >>> >> >> Noe-Payne > >>> >>> >> >> >> >> >> >>>> >> >> >> >>> >> <[email protected] > >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 > >>> >>> >> >> >> >> >> >>>> >> > >>> >>> >> >> >> >> >> >>>> > >>> >>> >> >> >> >> >> > >>> >>> >> >> >> >> > >>> >>> >> >> >> > >>> >>> >> >> > >>> >>> >> > >>> >>> > >>> >
