One big webservice or lots of little ones?

Question

I'm building a set of methods to provide functionality to a number of different web applications, the methods basically get some data from SQL perform some operations on it and then pass it back to the calling application. They have to be implemented via web services.

So my question is what are the pros and cons between creating one massive webservice with lots of methods or dividing the methods up into logical groups and encompassing each of these into their own webservice. I think there will be a lot of subsequent methods implemented after the first version so whatever I do has to be easily maintainable.

If it has any impact on the answers I'm using .Net 3.5, C# and can't use WCF at the moment.

Answer 1

Some food for thought: Granular is good for more control, but it does have an associated performance penalty. If you go too granular, you may end up with an API that would require multiple network round-trips to do anything non-trivial. So, I would keep the network round-trip and latency in mind when designing the service. If the service is to be potentially located across a WAN, I would refrain from making a "chatty" interface and go for methods that return more data.

As a for instance, prefer retrieving an entire user plus their order history, instead of one distinct call for the user's data and another distinct call for the order history if most of the time the user and order history will both be required by the caller. You need to consider how the service is going to be used, and factor your interfaces accordingly.