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

We had to make the same decision several years ago. We went with the very granular approach. It served us very well. It allowed us to turn out webservices into an API of sorts. This was not our original intent, but it worked very well for us.

Randy

Answer 2

One big
Pros:

• No need to maintain a lot of service references.
• Can be easier to find what you're looking for, and get an overview.

Cons:

• If you ever update 1 signature, clients will need to add that huge (?) reference and reread the WSDL.
• Harder to delegate the work if a lot of clients are present.

Lotsa small ones
Pros:

• Easier to maintain. One change in a signature is a small change for the clients.

• Easier to use different hosts.

Cons:

• Can easily grow into a mess.

My advice is to look at the logic packages of your services. Are clients likely to use a portion of your services, or all of them? Are there any cases where they will need to use half of service #1 and half of service #2? Try to figure out what the common scenarios are, and design your services so that they will only need to create one proxy for it to work.

Answer 3

The advantage to splitting them up into separate services is that if you start to run into performance problems you can always move individual services onto separate servers.

The advantage of keeping them together in one big service is that certain code (e.g. reading config information from a file) is going to be the same across all services and you can re-use the code if it's all in a single service (you could also put your re-used code in a separate class library).

You could make arguments for either case. The two biggest questions I would have are: 1) Are the services related? Does it make sense to group them together or are you just grouping them together for convenience? If they are related, it might make sense to keep them together.

2) What kind of load do you expect? Can you realistically expect one server to handle the load of all the services for the next couple of years? If not, it might be better to break them apart now.

Answer 4

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.