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

On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > > > ----- Original Message ----- > | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; > | To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > | Sent: Monday, April 8, 2013 1:22:19 PM > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested > endpoints > | > | OK, with the following server API: > | > | http://some.server.com/posts/1 > | http://some.server.com/posts/1/comments > | (and NO 'comments' collection on the ' http://some.server.com/posts/1 ' > | response) > | > | Does this (today) 'myPipe.read(1)' already read the specific comments ( > | http://some.server.com/posts/1/comments ) ?? > | > | ======= JAVA API ======= > | Class Post: > | - string: id; > | - string: title; > | - string: postContent; > | - List<Comment> comments; > | Class Comment: > | - string username; > | - string comment; > | > | Or would the IMPL expect an 'embedded' _comments_ collection on the > response > | of "GET http://some.server.com/posts/1 " ? > > It will not read /posts/1/comments if the Pipe's endpoint is /posts. If > you have a comments collection on the post but no comments data in the > response then the value for getComments will just be null. > Ok - so this needs to be tweaked in Java too, since it's very common to model the REST endpoints like above; > | > | > | > | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < supittma(a)redhat.com > > | wrote: > | > | > | No. The get of pipe 1 would have to include the comments for get > comments to > | work > | > | Sent from my Android phone using TouchDown ( www.nitrodesk.com ) > | > | > | -----Original Message----- > | From: Matthias Wessendorf [ matzew(a)apache.org ] > | Received: Monday, 08 Apr 2013, 12:04PM > | To: AeroGear Developer Mailing List [ aerogear-dev(a)lists.jboss.org ] > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested > endpoints > | > | > | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < supittma(a)redhat.com > > | wrote: > | > | > > | > > | > ----- Original Message ----- > | > | From: "Matthias Wessendorf" < matzew(a)apache.org > > | > | To: "AeroGear Developer Mailing List" < > aerogear-dev(a)lists.jboss.org > > | > | Sent: Monday, April 8, 2013 10:28:46 AM > | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested > | > endpoints > | > | > | > | or, like before said - reading "lists" (e.g. all the comments for > | > specific > | > | blog post): > | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 > | > | > | > | > | > | For Java.... I guess...... resolving this URL: > | > | http://some.server.com/posts/1/comments > | > | > | > | could be done with this - right ? > | > | > | > | ======= > | > | Class Post: > | > | - string: title; > | > | - string: postContent; > | > | - List<Comment> comments; > | > | Class Comment: > | > | - string username; > | > | - string comment; > | > | > | > | > | > | // get all the comments for 1: > | > | Post myPostOne = postPipe.read("1"); > | > | myPostOne.getComments(); > | > | > | > | // get all the comments for 2: > | > | Post myPostTwo = postPipe.read("2"); > | > | myPostTwo.getComments(); > | > | ======= > | > > | > It can be done with that yes. My concern was more when we had a Pipe > of > | > type <Post> and a readForResource(String property) method. > | > | > | Ok - one more question > | > | > | So... when doing: myPipe.read(1); does that "only" issue a GET against > the ' > | http://some.server.com/posts/1 ' resource? > | > | A second get, for the comments collection is than issued when calling > | myPostOne.getComments();? > | (GET against ' http://some.server.com/posts/1/comments' )? > | > | > | > | > | > The type information of the property isn't available unless we can > infer > | > it from the Post object. > | > > | > | > | > | > | > | > > | > > | > | > | > | > | > | Greetings, > | > | Matthias > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < > matzew(a)apache.org > > | > | wrote: > | > | > | > | > | > | > | > | Thought a bit more about it and chatted with friends, > | > | > | > | the issue with the sub pipes is: it adds state and is perhaps an API > | > | construct that is a bit hard to understand (see all the discussions > here) > | > | > | > | Not sure - but currently we can access "kid resources", with our > API - > | > right > | > | ? > | > | > | > | https://gist.github.com/matzew/6ab432e437b9a017a21d > | > | > | > | > | > | Perhaps it's better to just keep it that way? This has the benefit > of > | > using > | > | an established and know API, the different pipes are accessible via > the > | > | pipeline object; > | > | > | > | And the code is not too much code; it's simply an explicit pipe ... > | > | > | > | > | > | > | > | > | > | > | > | > | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < > matzew(a)apache.org > | > | > > | > | wrote: > | > | > | > | > | > | > | > | > | > | > | > | > | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < > scm.blanc(a)gmail.com > > | > | wrote: > | > | > | > | > | > | > | > | > | > | > | > | > | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < > matzew(a)apache.org > | > | > > | > | wrote: > | > | > | > | > | > | > | > | > | > | > | > | > | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < > cvasilak(a)gmail.com > | > | > > | > | wrote: > | > | > | > | > | > | > | > | Hi > | > | > | > | some comments > | > | > | > | I believe the method can't be used since you don't know the team > for the > | > | players so you can't retrieve the pipe directly..right? > | > | > | > | Isn't that really up to the impl of the rest service? > | > | They could return a list of teamsHePlayed for; > | > | > | > | So, let's not tie this API to a specific, not existing RESTful > service; > | > | > | > | +1, we don't need to care about that, we must just focus on how we > can > | > | declare and call nested pipes. > | > | > | > | > | > | > | > | > | > | yep > | > | > | > | I guess this is perhaps the closest we can come to : > | > | > | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe subPipe:@"owners" > | > | for:@"newyork"]; > | > | > | > | and than.... on the 'leaguesPipe' you can access its kids with > something > | > like > | > | : > | > | > | > | NSArray* kids = [leaguesPipe subPipes]; > | > | > | > | > | > | However, that adds some state to a specific pipe object > | > | > | > | > | > | -M > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | getPlayers ( Callback < List < Player >> callback ) { > | > | pipe . get ( "player" ). read ( callback ); > | > | } > | > | > | > | Further my questions is, how is a third (or arbitrary) nested > resources > | > are > | > | supported? I mean for a url schema like this > | > | > | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} > | > | > | > | first we access the leagues: > | > | --- > | > | getLeagues(Callback<List<Leagues>> callback) { > | > | pipe.get("leagues").read(callback); > | > | } > | > | --- > | > | then the teams for this league: > | > | --- > | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> callback) { > | > | pipe.junction("league","team").read(leaque, callback); > | > | } > | > | --- > | > | ..and then we access the "Players" for a "Team": > | > | --- > | > | getPlayersOnTeam(Team team, Callback<List<Player>> callback) { > | > | pipe.junction("team","player").read(team, callback); > | > | } > | > | --- > | > | But where is the "League" information to fill the "/leagues/{id}..." > | > path? > | > | > | > | > | > | I'd assume the information is 'inherited' out of a given pipe, when > | > doing the > | > | 'join' > | > | > | > | e.g. like > | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); > | > | > | > | not sure... > | > | > | > | > | > | > | > | > | > | Unless you mean something like: > | > | --- > | > | getPlayersOnTeam(Leaque league, Team team, Callback<List<Player>> > | > callback) { > | > | pipe.junction("league", "team","player").read(league, team, > callback); > | > | } > | > | > | > | I am not sure if that is really easy to understand/use > | > | > | > | Yes and the term "junction" is a bit confusing as it don't express > | > explicitly > | > | a parent/child relation. > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | --- > | > | > | > | probably I am missing sth.. > | > | > | > | Thanks, > | > | Christos > | > | > | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < supittma(a)redhat.com > > | > wrote: > | > | > | > | > | > | > | > | What if we create a new metaphor, a Junction. > | > | > | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a > | > | > | > | It joins two pipes together and can be used over and over again with > | > | different data? > | > | It isn't a Pipe though, but perhaps that could be changed to look > more > | > like > | > | Christos's previous example. > | > | > | > | At the very least I like the words "junction" or "join" more than > "of" > | > | > | > | ----- Original Message ----- > | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > > | > | | To: "AeroGear Developer Mailing List" < > aerogear-dev(a)lists.jboss.org > > | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM > | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for nested > | > | | endpoints > | > | | > | > | | > | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < > matzew(a)apache.org > > | > | | wrote: > | > | | > | > | | > | > | | > | > | | > | > | | 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 ? > | > | | > | > | | > | > | | Just a thought is instead of using Pipe, to continue using > Pipeline > | > adding > | > | | an > | > | | extra parameter " of" for specifying the parent : E.g.: > | > | | > | > | | ….. > | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; > | > | | > | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" of > | > | | :leaguesPipe > | > | | for:@"seattle"] > | > | | > | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline subPipe:@ > "players" > | > of: > | > | | allTeamsInSeattlePipe for:@"trebuchet"]; > | > | | ….. > | > | | > | > | | > | > | | Wdyt? > | > | | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | | -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(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 > | > | | > | > | | > | > | | > | > | | -- > | > | | 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 > | > | | > | > | | > | > | | > | > | | -- > | > | | 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 > | > | > | > | > | > | _______________________________________________ > | > | 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 > | > | > | > | > | > | > | > | -- > | > | Matthias Wessendorf > | > | > | > | blog: http://matthiaswessendorf.wordpress.com/ > | > | sessions: http://www.slideshare.net/mwessendorf > | > | twitter: http://twitter.com/mwessendorf > | > | > | > | > | > | > | > | -- > | > | Matthias Wessendorf > | > | > | > | blog: http://matthiaswessendorf.wordpress.com/ > | > | sessions: http://www.slideshare.net/mwessendorf > | > | twitter: http://twitter.com/mwessendorf > | > | > | > | > | > | > | > | -- > | > | 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 > | > > | > | > | > | -- > | 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 > | > | > | > | -- > | 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 > -- 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