Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints

I'll leave that decision to others. It would be easy enough for JS to just provide this as an object representing the nesting that I would just translate to a URI but it may not be that easy for others. On Mar 14, 2013, at 9:26 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: sure ... :) now you are addressing the entire graph ?! :) Well... not sure about something proper... On Thu, Mar 14, 2013 at 3:16 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > Ok, > Do we limit the depth to 1 ? > Because in theory we could have > > /companies/1/teams/1/slackers > > > > On Thu, Mar 14, 2013 at 3:10 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Mar 14, 2013, at 3:48 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >> >>> Hi, >>> While I was playing with scaffolding and tried to build a simple Blog >>> Application with Aerogear I faced the current situation : >>> I have a *Post* object which contains many *Comment* objects. Now I >>> want to call my Post pipe to retrieve the related comments, I have >>> currently 2 options : >>> * >>> * >>> */posts/1* -> assuming comments will be implicitly retrieved (eager >>> loading) >>> */comments/?postid=1* >>> >>> But regarding our model the correct form should be : >>> >>> */posts/1/comments* >>> >> >> >> +1 >> that is the ideal way to model URIs for "nested" resources. >> >> >> +1 >> >> >> See [1], extracted from [2] >> >> >> >>> * >>> * >>> But, AFAIK, with the current API, it is not possible to define this >>> last pattern (at least for JS and iOs, confirmed by Matzew). When doing a >>> *read *we can pass an *id *option but as mentioned in the doc, this id >>> will always be append to the endpoint. >>> >> >> >> Well, it is possible - but in a very (IMO) ugly way: >> >> https://gist.github.com/matzew/6ab432e437b9a017a21d >> >> >> +1 - Ugly >> >> >> >> >> >>> >>> IMO, we should be able to support this pattern but for now I'm not >>> really sure how to specify this in our API, so if you have any ideas >>> feedback this thread has been made for you ! >>> >> >> >> >> Suggestion: Enhance the read function - example: >> >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >> >> >> +1 - So for JS we could just add a 'resource' (not crazy about that >> name) option to the read options which, if present, would be tacked on to >> the url after the id. >> >> >> >> -Matthias >> >> >> [1] >> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >> [2] http://www.infoq.com/articles/rest-introduction >> >> >> >> >>> >>> Seb >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf___________________________________________... >> >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev