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

ok great, will collect the ideas proposed in the thread to two documents (spec and samples) so we all have a clear picture where we are.

Christos

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

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