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

Matthias Wessendorf matzew at apache.org
Tue Apr 2 09:03:41 EDT 2013


Inline ;-)


On Tue, Apr 2, 2013 at 2:51 PM, Christos Vasilakis <cvasilak at gmail.com>wrote:

> Hi
>
> answers inline
>
> On Apr 2, 2013, at 2:22 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
>
>
> 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;
>
>
> Internally, using the order of the nested resource names in the array, I
> built two pipes in that order,  that is
>
>  soccer.org/leagues/{id}/teams/  (1)
>  soccer.org/leagues/{id}/teams/{id}/players  (2)
>
> but as you said, it can be easily confused..
>
>
>
>
>> }];
>> -----
>>
>> 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…
>
>
> agree. Basically you access the pipe "teams" filling the parent {id}'s
> with the values.
>
>
>
> 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?
>
>
> correct, no change to how the leaguesPipe works.
>
>
>
> 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 ?
>
>
> I really *LIKE* the idea!   +1000
>
> It's verbose enough and it's easy to set up the nested pipes.
>
> two comments:
>
> a)
>
> For accessing a sub-nested pipe of a nested one I assume there will be
> something like the following e.g:
>
> soccer.org/leagues/seatle/teams/ ->
> id<AGPipe> *allTeamsInSeattlePipe* = [leaguesPipe subPipe:@"teams" for:@
> "seattle"];
>
>
> soccer.org/leagues/seatle/teams/trebuchet/players ->
> id<AGPipe> allPlayersInTrebuchetPipe = [*allTeamsInSeattlePipe* subPipe:@"players"
> for:@"trebuchet"];
>
> right?
>

yes, that would be correct (I had to think for a bit - not sure the API is
named good enough :))



>
> b)
>
> I assume for passing the configuration for this pipe there can be another
> method [optional] passing the PipeConfig if the user wants to override any
> setting for this particular pipe e.g:
>
> id<AGPipe> allTeamsInSeattlePipe = [leaguesPipe subPipe:@"teams" for:@"seattle"
> config:^(id<AGPipeConfig> config) {
>  setRecordId:..
>  setTimeout..
> ...
> }];
>

Oh - good point.... I forgot to override some inherited settings...


Now.... we move the pipe factory into the pipe.....

Two thoughts....

1) the 'original' leaguesPipe has no clue about the subpipes, right ?
2) should a pipe offer a 'getter' for all it's sub pipes ?

-M


>
>
> Thanks,
> Christos
>
>
>
>
>
>
>
>
>
>>
>> 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
> _______________________________________________
> 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/01eeaf8b/attachment-0001.html 


More information about the aerogear-dev mailing list