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
