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

Tue Apr 2 07:22:22 EDT 2013

On Thu, Mar 28, 2013 at 1:03 PM, Christos Vasilakis <cvasilak at 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 agree w/ Luke - interesting proposal

>
> 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
>

I would read the nested pipes here as:
* soccer.org/leagues/{id}/teams
* soccer.org/leagues/{id}/players

which does not match the above URL samples, you gave;

> }];
> -----
>
> 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"]
> ...
>

Hrm..... I am confused...
What is the name of the first argument? Also the path params, not sure
about them...

I think this proposal differs from how we currently read a specific entry:
(soccer.org/leagues/seattle)

[leaguesPipe read:@"seattle" success:callback failure:othercallback];

So i guess ... the above would return details about the "Seattle League",
right?

Now... I think... If I wanted a "sub"/"nested" pipe, from that leagues pipe
(e.g. to work with teams in the "Seattle Leaguue" ... I think there are two
ways...

a) use the Pipeline as it's factory (I guess that's what you proposed)
b) use the actual pipe to create a nested pipe, by leveraging the available
information

Here is, I think, how the b) could look for this URL:

id<AGPipe> allTeamsInSeattlePipe = [leaguesPipe subPipe:@"teams"
for:@"seattle"];

Now we have a subPipe that has this (inherited) URL: ->
soccer.org/leagues/seattle/teams

And, if I want to issue a a read against "
soccer.org/leagues/seattle/teams/trebuchet" would look like:

[allTeamsInSeattlePipe  read:@"trebuchet" success:callback
failure:othercallback];

Now, imagine the API could also return the owners of a certain lagues - the
"sub pipe creation" could be done like:

Here is, I think, how the b) could look for this URL:

id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners"
for:@"newyork"];

Reading details about Mr. Brown (some owner in the list, that has the ID
19) would be like:

[allOwnersInNewYorkPipe  read:@"19" success:callback failure:othercallback];

So... this would match a read to: "soccer.org/leagues/newyork/owners/19"

Does that make sense ? Any thoughts ?

>
> 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 at 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 at 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 at 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 at 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 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.
>>> >>
>>> >> 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/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
>>>
>>>  -- qmx
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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
>
>
>
> _______________________________________________
> 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/20130402/d9e58125/attachment-0001.html 