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