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