Curious to find out whether gRPC is the future? This article aims to explain two architectural APIs styles: REST and gRPC. Before we move on to their differences, we will first explain what an API is and why it is essential for microservices infrastructures.
Afterward, we will describe how RPC is the base for gRPC and consider the critical aspects of differentiation between gRPC and REST APIs. Considering their comparison, we will finally analyze when to use one architectural type or the other.
Table of Contents
Understanding what an API is
➤ APIs and Microservices
What is RPC?
What is REST?
What is gRPC?
gRPC vs REST: comparison
➤ HTTP 1.1 vs HTTP 2
➤ Browser Support
➤ Payload Data Structure
➤ Code Generation Features
➤ gRPC vs REST: comparison table
When to use gRPC vs REST?
Conclusion
Understanding what an API is
APIs stand for Application Programming Interfaces. These interfaces serve as a software intermediary that establishes specific determinations and rules for applications to interact and talk to each other. An API is responsible for delivering a response from a user to a system, which in turn is sent back from the system to the user. Does it still sound a bit confusing?
Let's imagine we are booking a hotel. We go to the hotel booking page on our laptop, and that page - which is connected to the Internet - sends data (our request) to a server. In turn, the server retrieves the data, interprets it, and then, once the required actions are executed, it sends a response back to us with the information on our interface. This process happens thanks to APIs.
An API specifies the types of requests that one application (web page or mobile app) can make to another and further establishes: how to make those requests; which data formats to use; and the practices that users have to follow.
This article compares gRPC (Google Remote Procedure Call) and REST (Representational State Transfer) because they represent the two most popular architectural styles when creating APIs.
APIs and Microservices
On the one hand, in a monolithic application, all the project's functionalities are included in a single unit, more precisely, in a single codebase. On the other hand, a microservice architecture comprises several smaller services that communicate with each other using protocols like HTTP. The component services that are part of the microservices architecture communicate and interact with each other through APIs. In other words, APIs allow all the services that are integrated into a microservice application to connect and communicate.
The most used architectural style is the REST API. However, there are three main models when building an API: RPC (Remote Procedure Call), REST (Representational State Transfer), and GraphQL. In this article, we will focus on the first two.
What is RPC?
RPC uses a client-server model. The requesting server (in other words, the client) requests a message that is translated by the RPC and sent to another server. Once the server receives the request, it sends the response back to the client. While the server is processing this call, the client is blocked, and the internal message passing within servers is hidden.
Further, RPC allows the client to request a function in a particular format and receive the response in the exact same format. Nonetheless, the method of submitting a call with RPC API is found in the URL. RPC supports remote procedure calls both in local and distributed environments.
Like a REST API, RPC also establishes the rules of interaction and how a user can submit "calls" (requests) to invoke methods that communicate and interact with the service.
What is REST?
When using REST APIs, the response from the back-end data is passed to the clients (or users) through the JSON or XML messaging format. This architectural model tends to follow the HTTP protocol. However, it is not uncommon for RPC designs to also select a couple of ideas from HTTP while maintaining the RPC model. In fact, the majority of modern APIs are implemented by mapping the APIs to the same HTTP protocol, despite the model used (RPC or REST).
When the REST API is publicly available, each service that integrates the microservice application can be presented to the user/client as a resource which can be accessed through the following HTTP commands:GET, DELETE, POST, and PUT.
What is gRPC?
gRPC stands for Google Remote Procedure Call and is a variant based on the RPC architecture. This technology follows an RPC API's implementation that uses HTTP 2.0 protocol, but HTTP is not presented to the API developer nor to the server. Hence, there is no need to worry about how the RPC concepts are mapped to HTTP, which reduces complexity.
Overall, gRPC aims to make data transmissions between microservices faster. It is based on the approach of determining a service, establishing the methods and respective parameters to enable remote calling and return types.
Moreover, it expresses the RPC API model in an IDL (interface description language), which offers a more straightway to determine remote procedures. By default, the IDL uses Protocol Buffers (but other alternatives are also available) to describe the service interface as well as the payload messages' structure.
gRPC vs REST: comparison
Now that we have an overview of gRPC and REST, let's look at their main differences.
HTTP 1.1 vs HTTP 2
REST APIs follow a request-response model of communication that is typically built on HTTP 1.1. Unfortunately, this implies that if a microservice receives multiple requests from multiple clients, the model has to handle each request at a time, which consequently slows the entire system. However, REST APIs can also be built on HTTP 2, but the request-response model of communication remains the same, which forbids REST APIs to make the most out of the HTTP 2 advantages, such as streaming communication and bidirectional support.
gRPC does not face a similar obstacle. It is built on HTTP 2 and instead follows a client-response communication model. These conditions support bidirectional communication and streaming communication due to gRPC's ability to receive multiple requests from several clients and handle those requests simultaneously by constantly streaming information. Plus, gRPC can also handle "unary" interactions like the ones built on HTTP 1.1.
In sum, gRPC is able to handle unary interactions and different types of streaming:
- Unary: when the client sends a single request and receives a single response.
- Server-streaming: when the server responds with a stream of messages to a client's request. Once all the data is sent, the server additionally delivers a status message to complete the process.
- Client-streaming: when the client sends a stream of messages and in turn receives a single response message from the server.
- Bidirectional-streaming: the two streams (client and server) are independent, meaning that they both can transmit messages in any order. The client is the one who initiates and ends the bidirectional streaming.
Browser Support
This aspect is probably one of the main REST API advantages over gRPC. On the one hand, REST is fully supported by all browsers. On the other hand, gRPC is still quite limited when it comes to browser support. Unfortunately, it requires gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP 2. Therefore, gRPC ends up being mainly used for internal/private systems (API programs within a particular organization’s backend data and application functionality).
Payload Data Structure
As previously mentioned, gRPC uses Protocol Buffer by default to serialize payload data. This solution is lighter since it enables a highly compressed format and reduces the messages' size. Further, Protobuf (or Protocol Buffer) is binary; thus, it serializes and deserializes structured data in order to communicate and transmit it. In other words, the strongly typed messages can be automatically converted from Protobuf to the client and server's programming language.
In contrast, REST mainly relies on JSON or XML formats to send and receive data. In fact, even though it does not mandate any structure, JSON is the most popular format due to its flexibility and ability to send dynamic data without necessarily following a strict structure. Another significant benefit of using JSON is its human-readability level, which Protobuf cannot compete with yet.
Nonetheless, JSON is not as light-weight or fast when it comes to data transmission. The reason for that lies in the fact that when using REST, JSON (or other formats) must be serialized and turned into the programming language used on both the client and server sides. This adds an extra step to the process of transmitting data which can consequently damage performance and open a possibility for errors.
Code Generation Features
Unlike gRPC, REST API does not provide in-built code generation features, meaning that developers must use a third-party tool like Swagger or Postman to produce code for API requests.
In contrast, gRPC has native code generation features due to its protoc compiler, which is compatible with several programming languages. This is particularly beneficial for microservices systems that integrate various services developed in different languages and platforms. All in all, the built-in code generator also facilitates creating SDK (Software Development Kit).
gRPC vs REST: comparison table
| Features | gRPC | REST |
HTTP 1.1 vs HTTP 2 |
Follows a client-response model of communication and is built on HTTP 2, which allows for: streaming communication and bidirectional support. |
Follows a request-response model of communication and is typically built on HTTP 1.1. |
Browser Support |
Limited browser support. gRPC requires gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP 2. |
Universal browser support. |
Payload Data Structure |
gRPC uses Protocol Buffer by default to serialize payload data. |
REST mainly relies on JSON or XML formats to send and receive data. |
Code Generation Features |
gRPC has native code generation features. |
Developers must use a third-party tool like Swagger or Postman to produce code for API requests. |
When to use gRPC vs REST?
As mentioned, despite the many advantages gRPC offers, it has one major obstacle: low browser compatibility. Consequently, gRPC is a bit limited to internal/private systems.
Contrarily, REST APIs may have their disadvantages, as we have discussed, but they remain the most known APIs for connecting microservices-based systems. Plus, REST follows the HTTP protocol standardization and offers universal support, making this API architectural style a top option for web services development as well as app and microservices integrations. However, this does not mean we should neglect gRPC's applications.
gRPC architectural style has promising features that can (and should) be explored. It is an excellent option for working with multi-language systems, real-time streaming, and for instance, when operating an IoT system that requires light-weight message transmission such as the serialized Protobuf messages allow. Moreover, gRPC should also be considered for mobile applications since they do not need a browser and can benefit from smaller messages, preserving mobiles' processors' speed.
Conclusion
gRPC provides plenty of advantages. Unlike REST, it can make the most out of HTTP 2, using multiplexed streams and following the binary protocol. Plus, it offers performance benefits due to the Protobuf message structure, and let's not forget the in-built code generation features which enable a multilingual environment. These reasons make gRPC a promising API architectural style.
Nonetheless, the low browser support makes it challenging to compete with REST universal support. REST remains the glue in microservices systems and is the most popular solution. Thus, it is highly probable that it will be around for long and, truth be told, it is a very well-developed and successful architecture.
Want to read more about gRPC and REST?
More than 500.000 people read our blog every year and we are ranked at the top of Google for topics such as gRPC and REST. If you liked this blog post and would love to read all our blog posts on gRPC and REST, 
Get the best content in your inbox
Besides our Blog, we also develop a monthly newsletter that provides great content for IT Professionals such as news, trends and tools. You can know more about it, see past editions and subscribe here.
