Message Broker vs API

REST APIs are commonly used for communications between microservices. The term Representational State Transfer (REST) defines a set of principles and constraints that developers can follow when building web services. Any services that adhere to them will be able to communicate via a set of uniform shared stateless operators and requests. Application Programming Interface (API) denotes the underlying code that, if it conforms to REST rules, allows the services to talk to one another.

REST and HTTP

REST APIs use Hypertext Transfer Protocol (HTTP) to communicate. Because HTTP is the standard transport protocol of the public Internet, REST APIs are widely known, frequently used, and broadly interoperable.

However, HTTP is a request/response paradigm protocol, so it is implemented in situations that call for a synchronous request/reply. This means that services making requests via REST APIs must be designed to expect an immediate response. But if the client destined to receive and process the response is down, then the sending service will be blocked while it awaits the reply. This requires that the overhead of failover and error handling logic needs to be built into both of these services.

Message Broker

The difference with a message broker is that it enables asynchronous communications between services so that the sending service does not need to wait for the receiving service’s reply. The result is that it improves fault tolerance and resiliency in those systems where they’re employed. Additionally, there is the issue of scalability, the use of message brokers makes it easier to scale application systems since a pub/sub messaging pattern can easily support changing numbers of services.