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

[Matthias Wessendorf]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130314/8d9a110c/attachment-0001.html