Best Practices for Designing a Pragmatic RESTful API
This feels like a good place to get some opinions out there about an app I am working on.<p>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.<p>eg<p>/foo returns something like [1,2,3,4]<p>I then have to do 4 more http requests to /foo/1, /foo/2, /foo/3 and /foo/4.<p>Further, if a /foo/1 model contains for example a user, then /foo/1 would additionally contain userid of eg 101.<p>I would then have to do a /user/101 and ensure the foo model was populated.<p>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.<p>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<p>[
{fooid : 1, user : {id : 101, name 'bob'}, 	orders : [{id: A},{id : B}]},
{fooid : 2, user : {id : 102, name 'alison'}, 	orders : [{id: C},{id : D}]}
]<p>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.<p>What does HN think about these contrasting approaches?