The Yoga approach is simple. On top of your RESTful implementation, you can pass a selector which asks the server to return nested or non-default fields with the response.
For instance, here is a traditional REST request that gets the information for a user:
/user/2.json
A client developer can create a very simple profile page with this data. Let's say the designers want to display list of the user's favorite artists on the same profile page. We add the selector as a parameter, like this:
/user/2.json?selector=:(favoriteArtists)
To take this yet a step further, grab the discography for those artists to display some album information on the same screen:
/user/2.json?selector=:(favoriteArtists:(albums))
Or maybe you want to emphasize the social-graph focused, and you want to find other people who like the same bands:
/user/2.json?selector=:(favoriteArtists:(fans))
Note that the circular reference does not continue to loop, since a selector has not been added to "fans".
This approach also works with calls that return collections of resources. Here we retrieve a list of all users in the database, and their favorite artists.
/user.json?selector=:(favoriteArtists)
Finally, here's an example of a deep-dive query that would take hundreds of queries with typical REST calls. It returns a list of all the songs by a user's friends' favorite artists:
/user/1.json?selector=:(friends:(favoriteArtists:(albums:(songs))))
As you can see Yoga creates a lot of flexibility for the client. All of these selectors are completely dynamic. As long as the fields are in the object map, Yoga will find them. To see more of what you can do, try out our selector builder GUI.