Having worked with both message queues and web services I decided to write a little bit about their differences. Throughout my career I have heard a lot of arguments for and against both of these communication types. My idea with this post is to get some of these thoughts down. I will refrain from using the term REST in this post as I think it often misunderstood as just being an endpoint using HTTP. I will instead use the term HTTP request, web service or web request. See this post for the difference between HTTP and REST. I will also use the term broker and message queue system interchangeably.
Client support
I think I would start with one of the strongest reasons to use web services over brokers. Almost all applications and programming languages today can do HTTP. It is very well adopted within the world of software development and is also used to serve the post you are reading right now.
In order to communicate with a broker you need a client. There might be a great client for your current programming language, but it may also be missing or faulty. HTTP is almost always built into programming languages or easily accessible. For both HTTP and message queues you can use any programming language. But HTTP is just more well adopted. Most developers are also familiar with the HTTP protocol, both the return codes and HTTP verbs are well known.
If you look at the API's of big companies they rarely give you an API for a message queue to use. They give you a HTTP endpoint, often using REST.
For both brokers and web services you can use different programming languages from client to client.
Setup and maintenance
One of the obvious things that you will need if you wish to use a message queue is a broker that can handle the messages. This will be a central piece of software that your services will communicate through. This has some negative and positive consequences. On the positive side your services will only need to know the broker and none of the other services. Which can make the communication more simple, as you have a centralised place to look for what is going on. It also further decouples the services. However the downside is that this piece of software needs to be upgraded from time to time. All software has to be upgraded but if this upgrade fails on your broker you are in for some trouble.
Using web services you will not have this central component, or do you? You may have a load balancer or a way to discover your services (HATEOAS for example). These components in your infrastructure are also important and require upgrades at a point in time. But there is a big difference between web services and brokers. Using a broker you build up state (messages). But your http requests towards your web services are stateless. So if you have a blue/green deployment of your upgrade you can always go back. However this is more complicated with a broker since messages can be stuck on the old installation.
Loadbalancing
Loadbalancing is different between broker implementations. But most brokers are able to loadbalance. The consumers of queues request messages and are given some by the broker, so the broker distributes the messages. This creates load balancing, so that the fastest consumer gets the most messages. As mentioned this is often built into the broker - at least in modern message queues.
For web services you often need a third party component to do your loadbalancing. There are many to choose from and they can do all sorts of things these days. This may take some configuration but is usually no big deal.
Persistence and publish/subscribe
Now we are getting to one of the great features that brokers have - they can persist messages. If your system goes down or the network goes down your messages are saved on the broker. Meaning they will get picked up when everything is up and running again. When the broker has received the message the requester (the one sending the message) can forget all about it. Even if the service - that this message is intended for - is down, the message will just wait in the queue until the service is up again. This gives some great flexibility, and does not force the requester to resend messages (this is of course needed if the broker itself is down).
If you are practicing microservices and running web services you may also have long chains of web requests. If one of these fails, a response has to be sent all the way back to the original requester - as the requester is waiting for a response. For message queues this can be avoided using publish/Subscribe. Services using a message queue system pick up their messages at their own chosen speed. The requester sending this message is not waiting around for a response from a downstream service. The requester (perhaps) only waits for an acknowledgement from the broker that it has received it.
So using a broker, consumers can consume at their own pace and you do not have to wait around for a response.
Message queues may also have the feature to publish the same message many times. Which is a great feature if you wish to send the same message to several services.
Where they are equal
"Most" queue systems do not care what type of message they send. It can be byte, XML, JSON and so on. The same applies to using web services. So none of them have an advantage over the other.
Both also have a one point of failure. For the messaging system it is the broker. For web services it is usually the load balancer. However web services may have an edge here as I believe it is more easy to switch out a load balancer (if you can redirect your traffic to it).
Summary
It should be said it is hard to rate "all the different message queue systems" against "HTTP". Message queue systems are different from one another. I have tried to take the most common features of them into account. However the message queue you are thinking of using, may have some features which can give you an edge in what you are doing.
Overall both message queue systems and web services can do the same things. Web services have a huge edge on how well adopted they are. It is also unmentioned that you may find web services easier to get started with - and we all like starting small. However using a message queue system you may get some extra features. Such as publish/subscribe - the requester does not have to wait for the request to be processed downstream. There may also be other features such as multi publishing and persistence of messages. But if you do not need any of these features, starting out with web services would be the simplest (I reckon).
Here I will make a small summary of the above.
Message queues
Pros
- Services do not have to know about each other, they only need to know the broker
- One place to look when communication goes wrong
- Often built in loadbalancing
- Can persist messages
- Consumers can consume messages at their chosen speed
- Builtin fire and forget
- Multipublishing (common feature of message queues)
Cons
- You need a client for the programming language you currently use
- Upgrades can be a pain
Web services
Pros
- All clients can do HTTP
- Often used in external communication
- Well-known and well defined status codes and verbs.
- You do not need a broker.. you can get started without
Cons
- Consumers have no control of the amount of messages that they get
- Has no built in fire and forget
- Can create long chains of web services calling each other and waiting for responses
That is it!
That was my message queues VS web services post. Let me know in the comments if you disagree with the contents!