In Microservices Communication Frameworks Part 1, EQengineered provided an overview of several communication frameworks commonly used in a microservices architecture. A typical microservices application has a communications architecture as shown in Image 1.

The communications among the services may be implemented any number of ways: REST, gRPC, SOAP, WebSocket, or a messaging framework.

In this post, EQengineered compares two of those frameworks—REST over HTTP/1.1 and gRPC over HTTP/2—and provides recommendations for choosing one over the other.

REST over HTTP

REST over HTTP, HTTP/1.1 specifically, is the most widely used architectural style used today for communications between services, externally or internally. REST stands for REpresentational State Transfer. In a REST based design, business entities and functions are considered resources, which are accessed using Uniform Resource Identifiers or URIs, and acted on by standard HTTP actions like GET, POST, PUT, PATCH, and DELETE. REST is a synchronous, stateless protocol, and information is exchanged among services using mostly text-based message formats like JSON, XML, or ODATA.

The communication architecture for a purely REST-based application will is depicted in Image 2 below:

Advantages of a REST-based API are:

It is an easy-to-understand text protocol.

HTTP is supported in nearly every framework and language, and has support for many content types.
Communication takes places over a scalable web Infrastructure built on top of HTTP.
High-quality HTTP implementations are available in almost every language.
There is wide support from browsers and tools for testing, inspection, and debugging.
The OpenAPI specification—an Interface Definition Language (IDL)—can be used to define structure and syntax of a REST API.

Among its limitations are:

In certain situations, REST’s text-based message format can increase network load, thus limiting performance.
There is no single standard for API contract, thereby requiring the developers to write client libraries to interpret and validate REST messages.
Streaming is difficult, even impossible, in some languages.
REST over HTTP is a synchronous protocol although some degree of asynchronous behavior can be implemented through techniques like polling and webhooks.

gRPC over HTTP/2

gRPC is a modern communication framework, which uses highly efficient HTTP/2 as its transport, and protocol buffer (or protobuf) as its binary messaging format. The style of communication in gRPC is known as RPC, or Remote Procedure Call, in which a procedure is remotely executed on a separate service. Unlike a REST API, which is designed in terms of resources (nouns) and actions (verbs), RPC APIs are often designed in terms of interfaces and methods, similar to the way a program is structured.

Although less established than REST or SOAP based services, gRPC is increasingly gaining popularity for implementing inter-services communication due to its scalability under high load. gRPC supports several connection options—single request/response, client and server streaming, and bidirectional streaming. gRPC can also push messages in real time without polling. Being relatively new, however, gRPC lacks extensive tooling and browser support.

A typical gRPC-based architecture, as shown in Image 3, has its external access point usually implemented in the REST style because of its ubiquity and ease of use, while the internal services are implemented in gRPC for increased performance, bi-directional or real-time messaging, and stricter type checking.

Most of gRPC’s advantages arise from two important design decisions—using HTTP/2 for transport, and protocol buffers from messaging.

HTTP/2 communication is binary, and utilizes header compression, making sending and receiving messages compact and efficient. Also, HTTP/2 supports bi-directional communications and multiple parallel requests on the same channel as well as streaming for asynchronous information exchange.

Protocol Buffers provide an efficient, platform-neutral serialization format for message exchange. A text-based Interface Definition Language (IDL) allows strongly typed service contracts to be built for both clients and services, .

Advantages of a gRPC API are:

gRPC payloads can be much smaller than JSON messages.
Unlike JSON, protobuf can specify field types and add validations.
gRPC APIs are several times faster than REST+JSON ones.
Support for different programming languages achieved through automatic code generation.
gRPC supports both synchronous and asynchronous behavior through its connection options—single request/response, client and server streaming, and bi-directional streaming.

Among its disadvantages are

Its immaturity as it is relatively new resulting in lack of tooling and browser support.
Not all gRPC features are available via web clients.
Unlike a REST API, whose design is constrained by the limited number of HTTP actions, RPC based APIs could rapidly proliferate into a large number of service calls which may be difficult to maintain.
Unlike XML and JSON, gRPC’s message format—protocol buffer—is in binary and not human readable which is often an important consideration for analyzing payloads, troubleshooting, etc.
gRPC lacks support for wide variety of content types.

Considerations

Here are some things to think about when choosing how to implement an API.

Interface design

A REST-based API is defined in terms of resources and HTTP verbs. It has well-defined behavior in terms of statelessness, side-effects, and response codes. A gRPC-based API is defined in terms of operations, which look like local method calls, which can lead to a proliferation of method definitions, unless appropriate care is taken during interface design.

Efficiency

In terms of speed, memory, and payload size, a gRPC-based interface is more efficient than REST over HTTP. That said, while considering efficiency, the performance of the entire system should be considered. Simply choosing a more efficient messaging protocol will not help if there are bottlenecks in other parts of the application.

Request-Response vs Streaming

REST over HTTP 1.1 uses a request-response model of communication, which introduces latency under heavy load when the server has to service multiple requests from multiple clients. gRPC, in contrast, takes full advantage of bidirectional streaming and real-time capabilities of HTTP/2.

Message format

REST interfaces communicate using text-based formats, most commonly JSON, while gRPC uses protocol buffer—a binary format. Although a binary format is generally faster than text-based formats, a JSON format has advantages in terms of interoperability because most languages and frameworks support JSON serialization. Text-based formats also lead to easier testing and debugging.

Compatibility and interoperability.

HTTP is supported in nearly every browser, framework and language. gRPC support among browsers, and languages, although growing, is more limited, as there is simply no browser API with enough fine-grained control over the requests. Browser based applications need a client-side library like gRPC-Web and a special proxy running on the server to enable limited support for gRPC.

In summary, REST is still the recommended API framework, given its wide support across browsers, languages, frameworks, and tools, unless the performance benefits of a binary protocol or the bi-directional streaming and real-time capabilities of HTTP/2 can be justified.

Microservices Communication Frameworks—Part 2 by Ranjan Bhattacharya