One big web service or many small ones?

Question

I create a set of methods to provide functionality for several 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 must be implemented through web services.

So my question is what are the pros and cons of creating one massive web service with a large number of methods or dividing methods into logical groups and including each of them in their own web service. I think that after the first version many subsequent methods will be implemented, so everything that I do should be easily maintained.

If this affects the answers I'm using .Net 3.5, C # and can't use WCF at the moment.

Answer 1

One big
Pros:

• No need to support many service links.
• It may be easier to find what you are looking for and get an overview.

Minuses:

• If you ever update 1 signature, customers will need to add this huge (?) Link and re-read the WSDL.
• It is more difficult to delegate work if there are many clients.

Little little
Pros:

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

• It’s easier to use different hosts.

Minuses:

• It can easily turn into a mess.

My advice is to look at the logical packages of your services. Can customers use part of your services or all of them? Are there any cases when they will need to use half of service No. 1 and half of service No. 2? Try to figure out what the common scenarios are and design your services so that they only need to create one proxy server to work.

Answer 2

Some food for thought: granules are good for more control, but they have a related performance limitation. If you go too detailed, you can get an API that will require several network trips to do something non-trivial. Therefore, when designing the service, I will maintain network connectivity and latency. If the service should be potentially located across the global network, I would refrain from creating a chat interface and switch to methods that return more data.

As an example, it is preferable to get the whole user plus the order history instead of one separate call for user data and another separate call for order history, if most of the time the history of users and orders of the caller is required. You need to think about how the service will be used and influence your interfaces accordingly.

Answer 3

We should have made the same decision a few years ago. We went with a very granular approach. It served us very well. This allowed us to turn web services into APIs. This was not our initial intention, but it worked very well for us.

Randy

Answer 4

The advantage of dividing them into separate services is that if you start to encounter performance problems, you can always move individual services to separate servers.

The advantage of storing them in one big service is that a certain code (for example, reading configuration information from a file) will be the same for all services, and you can reuse the code if all of this is in one service (you can also put your reused code into a separate class library).

You can make arguments for both cases. The two biggest questions that I would have are: 1) Are services related? Does it make sense to group them together or just group them for convenience? If they are connected to each other, it makes sense to keep them together.

2) What load do you expect? Can you really expect that one server will handle the load on all services over the next few years? If not, it might be better to break them apart.