+1 for approach #1, seems clean
On Apr 10, 2013, at 11:47 AM, Kris Borchers <kris@redhat.com> wrote:

I would vote for Approach #1 in the gist. I believe that would be the best option across all libraries.

On Apr 10, 2013, at 9:48 AM, Christos Vasilakis <cvasilak@gmail.com> wrote:

Hi

I've prepared a document[1]  that collectively describes the different approaches discussed in this thread for supporting the nested resources. It is split in two sections, ones that don't require modification to the existing API and ones that do

Please have a look and let me know if I miss sth or interpret one approach wrong.

Thanks
Christos


On Apr 9, 2013, at 10:19 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:

Hey,
Like paging, could we start 2 gists : one with a side to side techno samples and another one with high level Specs ? I start a bit to get lost in this thread :)
Just one remark when reading the last messages, one "must have" is to be able to retrieve all the comments for a post without EVER retrieving the  post record, so 
/posts/1/comments will retrieve all the comments for post 1 but will actually never call posts/1 : in this covered in your last examples ? (spec could be : "by-pass parent GET resource"
Seb



On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf <matzew@apache.org> wrote:



On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma@redhat.com> wrote:


----- Original Message -----
| From: "Matthias Wessendorf" <matzew@apache.org>
| To: "AeroGear Developer Mailing List" <aerogear-dev@lists.jboss.org>
| 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@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@apache.org ]
| Received: Monday, 08 Apr 2013, 12:04PM
| To: AeroGear Developer Mailing List [ aerogear-dev@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@redhat.com >
| wrote:
|
| >
| >
| > ----- Original Message -----
| > | From: "Matthias Wessendorf" < matzew@apache.org >
| > | To: "AeroGear Developer Mailing List" < aerogear-dev@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@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@apache.org
| > | >
| > | wrote:
| > |
| > |
| > |
| > |
| > |
| > |
| > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < scm.blanc@gmail.com >
| > | wrote:
| > |
| > |
| > |
| > |
| > |
| > |
| > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < matzew@apache.org
| > | >
| > | wrote:
| > |
| > |
| > |
| > |
| > |
| > |
| > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < cvasilak@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@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@gmail.com >
| > | | To: "AeroGear Developer Mailing List" < aerogear-dev@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@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@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@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@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@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@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@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@lists.jboss.org
| > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | | >
| > | | > _______________________________________________
| > | | > aerogear-dev mailing list
| > | | > aerogear-dev@lists.jboss.org
| > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | | -- qmx
| > | |
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list
| > | | aerogear-dev@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | |
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list aerogear-dev@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list
| > | | aerogear-dev@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list
| > | | aerogear-dev@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list
| > | | aerogear-dev@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@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list
| > | | aerogear-dev@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@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > | |
| > | |
| > | | _______________________________________________
| > | | aerogear-dev mailing list
| > | | aerogear-dev@lists.jboss.org
| > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > |
| > | _______________________________________________
| > | aerogear-dev mailing list
| > | aerogear-dev@lists.jboss.org
| > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > |
| > |
| > | _______________________________________________
| > | aerogear-dev mailing list
| > | aerogear-dev@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@lists.jboss.org
| > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| > |
| > |
| > | _______________________________________________
| > | aerogear-dev mailing list
| > | aerogear-dev@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@lists.jboss.org
| > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
| >
| > _______________________________________________
| > aerogear-dev mailing list
| > aerogear-dev@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@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@lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev