On Thu, Mar 14, 2013 at 3:16 PM, Sebastien Blanc <scm.blanc(a)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(a)redhat.com> wrote:
>
> On Mar 14, 2013, at 3:48 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>
>
> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)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/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