On Mar 28, 2013, at 8:03 AM, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
Hi team,
on the last couple of days I have been playing with the idea on how to support nested
path in resources (a.k.a subresources). I am more keen in the idea to treat the nested
resources as full-time citizens. That is, treat the nested resource as a Pipe.
I came up with the following proposal (showing here in iOS)
For demonstration I use an imaginative Soccer API
e.g.
soccer.org/leagues/{id}/teams/{id}/players
when expanded with sample {ids}:
soccer.org/leagues/seattle/teams/trebuchet/players
During registration of the "parent pipe" (leagues) we specify the nested
resources for this Pipe using the "setNestedPipes" config option. Internally
the Pipeline during the setup of this pipe creates the corresponding nested pipes,
initialising their URL accordingly.
e.g.
-----
AGPipeline* pipeline = [AGPipeline pipelineWithBaseURL:BASE_SOCCER_APP_URL];
id<AGPipe> leagues = [pipeline pipe:^(id<AGPipeConfig> config) {
[config setName:@"leagues"];
[config setNestedPipes:[@"teams", @"players"]; // an array of
nested resources for this pipe
so since these are essentially pipes, how far can they be configured. for example,
could they have callbacks. and yes, i know that makes no sense
}];
-----
A new "pipe" method is added in the pipeline with params the Parent ID's of
this nested resource. Once returned you have a fill Pipe to invoke operations on.
-----
soccer.org/leagues/seattle/teams/trebuchet - >
[[pipeline pipe:@"teams" pathParams:@[@"seattle"]]
read:@"trebuchet"] ...
soccer.org/leagues/seattle/teams/trebuchet/players/foo - >
[[pipeline pipe:@"players" pathParams:@[@"seattle",
@"trebuchet"]] read:@"foo"] ..
-----
Wdyt?
Thanks
Christos
On Mar 18, 2013, at 1:12 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> Well, that would not be possible, for that you will have to create a
"child" pipe. But I agree, that is maybe no optimal ...
>
>
> On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman <supittma(a)redhat.com> wrote:
> On 03/15/2013 01:34 PM, Sebastien Blanc wrote:
>> I like the idea but I will more see that has a method/function for the
pipelineManager (and will be easier to implement in JS, I think) :
>>
>> var myParentPipe =
Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe
>>
>> var myChildPipe = Aerogear.Pipeline.fromParent(myParentPipe, {options} )
> What would it look like to get a child record from a parent?
>
>>
>>
>> On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>> What about this?
>>
>> Pipeline<Post> postPipeline = …
>> Post post = // get from the pipeline
>> Pipeline<Comment>
postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post)
>>
>>
>> On 15/03/2013, at 12:26, Summers Pittman <supittma(a)redhat.com> wrote:
>>
>> > On 03/14/2013 04:48 AM, Matthias Wessendorf 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.
>> >>
>> >> 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
>> >>
>> >>
>> >>
>> >>
>> >> 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
>> > I'm thinking of the inverse myself. Add a "ParentPath"
property which can be used to extract information from parent objects.
>> >
>> >
https://gist.github.com/secondsun/17ce96082eda37dbd10e
>> >
>> >>
>> >>
>> >> -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
>>
>> -- qmx
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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