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