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

[Kris Borchers]

It would require knowing the nested ID's though which is ugly and probably not ideal. I would be ok with just requiring nested calls to read to traverse down more than one level of nesting. At least for now.

Also, this is not for 1.0, right? We should not be making API changes before next week.

On Mar 14, 2013, at 9:35 AM, Kris Borchers <kris at redhat.com> wrote:

> 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 at apache.org> 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 at gmail.com> 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 at redhat.com> wrote:
>> 
>> On Mar 14, 2013, at 3:48 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>> 
>>> 
>>> 
>>> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc at gmail.com> 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/figure2.jpg
>>> [2] http://www.infoq.com/articles/rest-introduction
>>> 
>>> 
>>>  
>>> 
>>> Seb
>>>  
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130314/2c9c2225/attachment-0001.html