On Mon, Jul 22, 2013 at 1:15 PM, Erin Noe-Payne <[email protected]>wrote:
> I would also point out that we don't have a pressing need to actually > implement fields support. Our first use case - the angular client - > does not particularly need it since we will be using a > client-optimized "pagesForRender" endpoint anyway. > My only argument with this is on People. Right now you always get the full person record. I really think when you are searching for people you should get limited data (like facebook) and only see more detailed information when they are actually friends (and probably never see some data). > > As long as we ensure that our approach can be extended to support > fields selection in the future without refactor, that should be good > enough. > > On Mon, Jul 22, 2013 at 3: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 > > > > - 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 > >>> >>>> >> > >>> >>>> > >>> >
