We’re designing a data service that will store a large number of statistics about stocks, including historical data. The client will be a web application, which will need to pull various bits of data to show in different places on the site.
Since the different places need to show different sets of statistics, it’s not sensible for the service to simply offer one method which retrieves all the data that we have. Since there are so many different types of statistics, the service isn’t aware of the type of each one and simply stores them by key.
We previously tried to deal with this by having a number of methods which would return data objects with varying levels of detail, for example getBasicStockInfo, getStockInfo, getFeaturedStockInfo, getStockDetails. The trouble I found with this was that it became tedious to add new items of data to the objects (need to change server code), and each one would get bloated over time as fields are added for some specific locations on the front end. On the other hand, it would be impractical to have a method for each location on the front end that returns the specific data that’s needed in that location.
Does anyone have any ideas of how best to handle this situation?
One thing I’m considering is that the client would have to send a list of data keys for the data it wanted, and would get back a map of the statistics. I’m not sure if this is the way to go though, as the weight of parameters would get pretty heavy with the same ones being passed repeatedly from each location in the web app.
Your situation sounds very similar to how SalesForce.com designed their “Core Calls” (link).
They made all “data” objects an extension of a base object so that they can easily create a new one while reusing the same methods.