Designing Web services for AJAX Consumption

Question

We are in the process of designing/creating restful web services that will be consumed client side using XHR calls from various web pages. These web pages will contain components that will be populated by the data retrieved from the web services.

My question is, is it best to design the return data of the web services to match specifically what the client side components will require for each page? Therefore, only one XHR call will be required to retrieve all the data necessary to populate a specific AJAX component or to update a specific page. Or is it more advisable to develop generic web services, that match for instance a database schema, and will require multiple XHR calls client side to retrieve all the data to populate an AJAX component? The second approach seems to lead to some messy coding to chain calls together to retrieved all the data required before updating an AJAX component.

Hopefully this makes sense.

Answer 1

You should always design services based on what they are to provide. Unless you need a service that retrieves rows from the database, don't create one. You may find you need a service that returns complete business entities - they may be in multiple tables.

Or, you may just need a service to provide data for UI controls. In that case, that's what you should do. You may later find that two operations are returning almost the same data, so you may refactor that into one operation that returns the data for both.

Answer 2

My general rule of thumb is to do what ever is the smallest to transmit over the ajax call. In theory, the more data that is sent to the client the slower the update process. This, of course, would necessarily mean specific services for specific pages.