Some team members are advocating a very dogmatic approach to our eventually public facing REST API design where each REST end point of /foo results in a response of a list of some ids; each url can then be hit to fully populate the list.
eg
/foo returns something like [1,2,3,4]
I then have to do 4 more http requests to /foo/1, /foo/2, /foo/3 and /foo/4.
Further, if a /foo/1 model contains for example a user, then /foo/1 would additionally contain userid of eg 101.
I would then have to do a /user/101 and ensure the foo model was populated.
This can mean a simple list page with 10 on screen list items can easily create 1 + 10 + 10 = 21 http requests at a minimum. This is starting to add a lot of code complexity to managing the lists for sorting/filtering/updating purposes and managing the async requests in our AngularJS application.
The way I have worked before is to build a single end point of /foo with a paginator offset, and then that would return the entire object in an HTTP request, eg
[ {fooid : 1, user : {id : 101, name 'bob'}, orders : [{id: A},{id : B}]}, {fooid : 2, user : {id : 102, name 'alison'}, orders : [{id: C},{id : D}]} ]
This approach is less RESTful, but presents fewer issues when writing the API consuming code and is much more responsive from a latency point of view.
What does HN think about these contrasting approaches?