3 ms·
Another possible solution while sticking to REST: instead of embedding all the sub-objects have an "expand" query param where you can list all the sub-objects/r
by derrekl 11y ago
Another possible solution while sticking to REST: instead of embedding all the sub-objects have an "expand" query param where you can list all the sub-objects/relationships you'd like returned (EG: GET /playlists/ID?expand=tags,tracks) This way you can still do everything in one request but not bloat the response data structure for situations that don't need the sub-objects.
- timdorr 11y agoInterestingly, this is what Facebook does with their REST Graph API: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.5 https://developers.facebook.com/docs/graph-api/using-graph-a...
- paulddraper 11y agoYes, people do that all the time (e.g. of the top of my head, the Google Drive API). GraphQL is the natural extension of that, but more flexible and composable. I can get a user's name and email, and his friends names, with the cost of only one request and latency. You could change your REST API to do the same, but eventually you are reproducing the GraphQL equivalent.
- ollysb 11y agoGraphQL allows queries on those "expanded" sub-objects/relationships e.g. { playlist(id: 123) { tags, tracks(top: 5) } }
- 21echoes 11y agothis is how JSON-API works (Yehuda Katz, et al) http://jsonapi.org/ http://jsonapi.org/ `GET /articles?include=author,likes&fields[articles]=title,body&fields[people]=name`