The need for REST

REST is a dominant communication style used in SOAs. The business domain model is exposed as resources, where each resource is a published web service that has a defined API contract. These APIs take input using a message format such as JSON and share a response compliant to the protocol used. The microservice itself will have additional external dependencies, such as other APIs for which it acts as the REST client. Since the communication is over the network, it adds to the latency of a service call and thus it's vital to keep this communication lightweight. Each service would also need to be resilient to failures in other services.

To deal with failures and performance issues in other services, a service may incorporate strategies to overcome such cases. As an example, a users service may invoke the tickets API/resource for fetching the latest tickets. For some reason, if the tickets resource is unable to return a response (due to being slow or just not available), then the users service may use a default list which is kept internally for such cases. There are other strategies such as Bulkhead, Circuit-breaker, and Timeout that aid in dealing with the complexity of distributed communication.

Since microservices are fine-grained and modeled around business capabilities, they need to communicate with other services to get work done. In a large, complex application, a request often gets processed by more than one service. When processing a use case such as opening a new ticket or assigning a ticket to a user, there can be multiple services that will participate in this request. Microservices typically communicate with each other using REST. REST APIs facilitate lightweight communication over HTTP with flexible message formats, such as JSON/XML/text, and so on.

Each service publishes a API, which is then consumed by other services which act as its REST Client. Communication among the services can be point-to-point, or based on the use case, it can be asynchronous publish-subscribe model, which is also lightweight. Here's how the communication between our issue management microservices can be visualized:

As you can see, while this is an acceptable practice, as the number of services grow, so will the complexity inherent with point-to-point communication. Here's where an API Gateway adds value to microservices by providing certain benefits:

• A single entry point for external calls which gets routed to your services internally
• Acts as a layer of security, preventing any attacks from external sources
• Can act as an adapter, allowing for the handling of different message protocols
• Can provide monitoring and logging across services
• It also takes away the problem of service discovery from the clients
• The gateway can also apply the Circuit-breaker pattern for fault tolerance:

While the gateway does act as a layer for routing and message translations (almost similar to an enterprise service bus), it's important to keep it dumb and not add any business logic to it. This would allow the endpoints to evolve, without having to worry about part of its logic residing on the gateway.