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

Sebastien Blanc scm.blanc at gmail.com
Thu Mar 14 10:38:47 EDT 2013


The main question is : "What do we want ?"
Do we want to put some limit ? We must stay agnostic and imagine that we
could read third services accepting a lot of nested path params


On Thu, Mar 14, 2013 at 3:35 PM, 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/208a1780/attachment.html 


More information about the aerogear-dev mailing list