REST dominates the modern API landscape, especially when it comes to web applications and microservices-based infrastructures. However, REST isn’t the only API architecture available, and for a certain set of use-cases, the gRPC model has begun to play a small but crucial role. 

Whether you’re trying to figure out what “gRPC” means — or you’re considering gRPC as an alternative to REST APIs for your next development project — this guide will help you understand what gRPC is, why people use it, and how a gRCP API compares to a RESTful API.

We’re going to cover a lot of ground so feel free to use the following links to navigate: 

DreamFactory Hosted Trial Signup

Generate a full-featured,documented, and secure REST API in minutes.

Sign up for our free 14 day hosted trial to learn how.

Overview of REST vs. gRPC 

To understand REST and gRPC, we need to start with APIs (application programming interfaces). APIs provide rules and definitions that allow applications to communicate and interact with each other. An API defines the types of calls and requests that one application can make to another, how to make those requests, the data formats to be used, and the conventions that clients must follow. 

APIs also support the “pluggability” of applications that form a larger system because they allow two applications – even if they were written in different programming languages and running on different platforms – to communicate and interact with each other.

REST APIs and gRPC APIs refer to different architectural styles for building APIs. Here’s a brief definition of both:

  • REST (Representational State Transfer) API: REST is the most popular architectural style for building APIs, particularly for web-based applications and microservices-based infrastructures. REST defines specific constraints that support interoperability between microservices and internet-based applications. Although a REST API can receive and return messages written in a variety of formats, the most common format used is JSON. JSON is a text-based, human-readable format that is flexible, efficient, and language/platform agnostic.
  •  gRPC (Google Remote Procedure Call): gRPC is an open-source RPC architecture designed by Google to achieve high-speed communication between microservices. gRPC allows developers to integrate services programmed in different languages. gRPC uses the Protobuf (protocol buffers) messaging format, which is a highly-packed, highly-efficient messaging format for serializing structured data. For a specific set of use-cases, a gRPC API can serve as a more efficient alternative to a REST API (more on this later).

Here’s a simple matrix that compares the basics of REST APIs and gRPC:

CharacteristicgRPCREST API
HTTP ProtocolHTTP 2HTTP 1.1
Messaging FormatProtobuf (Protocol Buffers)JSON (usually) or XML and others
Code GenerationNative Protoc CompilerThird-Party Solutions Like Swagger
CommunicationUnary Client-Request or Bidirectional/StreamingClient-Request Only
Implementation Time45 Minutes10 Minutes

Understanding Microservices, REST APIs and RPC APIs

One of the best ways to understand the topic of APIs is to view APIs in the context of modern, microservices-based application development. Not only do APIs make microservices-based applications possible, but it’s in the context of microservices-based applications that gRPC APIs can — in some cases — serve as an alternative to REST APIs. 

What Are Microservices-Based Applications?

Microservices-based applications overcome the biggest limitations of traditional, monolithic applications. A monolithic application contains the programming for all of its services and features within a single, indivisible code-base that manages all of the services and features of the application. 

The problem is that — as developers bolt new services and features on top of the existing framework — it becomes increasingly difficult to modify, upgrade, and scale the application. Changing one part of the app can negatively impact other areas. After scaling, updating, and changing a monolith multiple times, the codebase eventually becomes so interdependent and difficult to understand that it’s necessary to redesign the entire system from scratch.

A microservices-based application architecture resolves this problem. This architectural style involves breaking a monolith into its component services and running each component as an autonomous application (called a microservice). These individual microservices then use APIs to interact and interact with each other. Together, this API-connected group of microservices forms the larger application architecture. 

Because of the way APIs allow autonomously-running microservices — even those coded in different languages and running on different platforms — to connect with each other, APIs allow you to achieve a pluggable, component-based system. Upgrading individual microservices is dramatically faster and easier because the changes you make to an autonomously-running service have less impact on the entire system. Scaling is easier and more efficient because resources can be diverted to the microservices that need it based on usage demands. Moreover, if one microservice fails or slows down, it’s less likely to bring down the entire infrastructure. All of this translates into more efficient, resilient, scalable, and flexible systems — and APIs are what make it all possible.

The most widely-used architectural style for APIs is the REST API. However, there are also RPC APIs and gRPC APIs. In the next sections, we’ll look at how these APIs compare to each other.


REST (Representational State Transfer) describes a client-server organization in which back-end data is made available to clients through the JSON or XML messaging format. According to Roy Fielding, an API qualifies as “RESTful” when it meets the following constraints:

  • A uniform interface: An API must expose specific application resources to API consumers.
  • Client-server independence: The client and the server function independently. The client will only know the URIs that point to the application’s resources. These are usually published in the API documentation.
  • Stateless: The server doesn’t save any data pertaining to the client request. The client saves this “state data” on its end (via a cache). Learn more about stateful vs. stateless systems here.
  • Cacheable: Application resources exposed by the API need to be cacheable.
  • Layered: The architecture is layered, which allows different components to be maintained on different servers.
  • Code-on-Demand (COD): This is the only optional REST constraint. This allows the client to receive executable code as a response from the server. In other words, it’s the server that determines how specific things get done.

Finally, the REST API architecture generally relies on HTTP protocol, and REST APIs are the most common format for building web applications and connecting microservices. When a REST API is made publicly available as a web service, each component (or service) provided by the web service is presented to clients as a resource. Clients can access these resources via a common interface that accepts different HTTP commands like GET, POST, DELETE, and PUT.


As a predecessor of REST, RPC (Remote Procedure Call) is a software architecture dating back to the 1970s. RPC allows you to invoke a function on a remote server in a particular format and receive a response in the same format. It doesn’t matter what format the server executing the request uses, and it doesn’t matter if it’s a local server or a remote server. RPC allows you to invoke a function on the server and receive the result in the same format.

The basic concept of an RPC API is similar to that of a REST API. The RPC API defines the rules of interaction and what methods a client can use to interact with it. Clients submit calls that use “arguments” to invoke these methods. However, with an RPC API, the method is found in the URL. The arguments that invoke the methods are found in the query string. To illustrate this, here’s how an RPC API request compares to a REST API request:

  • RPC: An RPC API request might use POST /deleteResource and have a query string that says { “id”: 3 }  
  • REST: A REST API request would write this request as DELETE /resource/2.

Understanding gRPC APIs

As a variant of the RPC architecture, gRPC was created by Google to speed up data transmission between microservices and other systems that need to interact with each other. Compared to REST APIs, gRPC APIs are unique in the following ways: 

  1. Protobuf Instead of JSON
  2. Built on HTTP 2 Instead of HTTP 1.1
  3. In-Born Code Generation Instead of Using Third-Party Tools Like Swagger
  4. 7 to 10 times Faster Message Transmission
  5. Slower Implementation than REST 

Let’s take a closer look at each of these differences between REST and gRPC APIs.

(1) Protobuf Instead of JSON/XML

Both REST APIs and RPC APIs send and receive messages using the JSON or XML messaging formats. They can use other formats too, but JSON and XML are the most common. Of these, JSON has become the most popular format because it is flexible, efficient, platform neutral, and language agnostic. It’s also text-based and human-readable, which makes it easy for human operators to work with. The problem is that for certain use-cases, JSON isn’t fast enough or light-weight enough when transmitting data between systems. 

In contrast to REST and RPC, gRPC overcomes issues related to speed and weight — and offers greater efficiency when transmitting messages — by using the Protobuf (protocol buffers) messaging format. Here are a few details about Protobuf:

  • Platform and language agnostic like JSON
  • Serializes and deserializes structured data to communicate via binary.
  • As a highly-compressed format, it doesn’t achieve JSON’s level of human-readability.
  • Speeds up data transmission by removing a lot of the responsibilities that JSON manages so it can focus strictly on serializing and deserializing data. 
  • Data transmission is faster because Protobuf reduces the size of messages and serves as a lightweight messaging format. 

(2) Built on HTTP 2 Instead of HTTP 1.1

Another way that gRPC boosts efficiency is through its use of the HTTP 2 protocol. 

REST APIs are usually built on HTTP 1.1, which uses a request-response model of communication. This means that when a microservice receives multiple requests from more than one client, it has to serve them one at a time, which slows the entire system. REST APIs can also use HTTP 2, they are still limited to the request-response model and don’t take advantage of HTTP 2 support for bidirectional, streaming communication.

In contrast, gRPC uses HTTP 2 and it takes advantage of HTTP 2 support for both client-response communication and bidirectional communication. As such, gRPC can manage “Unary” interactions that are similar to HTTP 1.1 (where the client sends one request and the server sends one response). At the same time, clients can also open long-lived connections where each RPC call opens a new HTTP 2 stream — also known as bidirectional, “multiplexing,” or streaming communication.

In HTTP 2, when a microservice receives multiple requests from more than one client, it achieves multiplexing by serving many requests and responses simultaneously. In this respect, gRPC APIs depart from the limitations of REST APIs in their capacity to stream information constantly. 

There are three types of streaming that gRPC makes available:

  • Server-side: A client sends a request message to a server. The server returns a stream of responses back to the client. After completing the responses, the server sends a status message (and in some cases trailing metadata), which completes the process. After receiving all of the responses, the client completes its process.
  • Client-side: A client sends a stream of request messages to a server. The server returns one response back to the client. It (usually) sends the response after receiving all of the requests from the client and a status message (and in some cases trailing metadata).
  • Bidirectional: A client and server transmit data to one another in no special order. The client is the one that initiates this kind of bidirectional streaming. The client also ends the connection.

(3) In-Born Code Generation Instead of Using Third-Party Tools

Code generation features are native to gRPC via its in-built protoc compiler. With REST APIs, it’s necessary to use a third-party tool such as Swagger to auto-generate the code for API calls in various languages. 

The protoc compiler that comes with gRPC is compatible with a wide range of programming languages. This makes gRPC excellent for polyglot environments — where you are connecting a lot of different microservices that are coded in different languages and running on different platforms. 

In contrast, REST API does not offer native code generation features. You have to use a third-party tool like Swagger to generate code for API calls in different languages. This isn’t an inconvenience, but it’s worth noting that gRPC doesn’t depend on any external tools for code generation. 

(4) 7 to 10 Times Faster Message Transmission

According to widely-cited tests published by Ruwan Fernando, gRPC API connections are considerably faster than REST API connections. In fact, he reported that they are 7 to 10 times faster: 

“gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC.”

(5) Slower Implementation than REST

Despite the benefits in message transmission speed, gRPC API implementation is a great deal slower than REST API implementation. According to Ruan Fernando, it takes approximately 45 minutes to implement a simple gRPC Service. It only takes about 10 minutes to implement a Web or REST API. 

Fernando reports that the additional implementation time reflects the lack of in-built support for gRPC in third-party tools. This is primarily because gRPC is not yet widely adopted, especially compared to the ubiquity of REST APIs. Here’s what Fernando says about gRPC implementation time: 

“I had to spend roughly 45 mins implementing this simple gRPC Service, where I only spent around 10 mins building the WebAPI. This is mainly due to REST becoming mainstream a long time back, and most major frameworks (i.e. ASP.NET Core MVC) having built-in support to quickly spin up such services (through convention & patterns).”

When Should You Use REST vs. gRPC?

Let’s compare when you should consider using REST APIs vs. gRPC APIs:

When to Use REST APIs

REST APIs are the most widely-used and popular APIs for connecting microservices-based infrastructures. Whether you are building an internal system or an open system that exposes its resources to the rest of the world, REST APIs are likely to remain the de facto choice for app integration for a very long time. Also, REST APIs are ideal when a system needs high-speed iteration and standardization of HTTP protocol. 

With its universal support from third-party tools, REST APIs should be your first consideration for app integrations, microservices integrations, and web services development. 

When to Use gRPC APIs

As for gRPC, most third-party tools continue to lack in-built features for gRPC compatibility. As such, gRPC is mostly relegated to building internal systems, i.e., infrastructures that are closed to external users. With that caveat in mind, gRPC APIs could be useful for the following circumstances: 

  • Microservices connections: gRPC’s low-latency and high-speed throughput communication make it particularly useful for connecting architectures that consist of lightweight microservices where the efficiency of message transmission is paramount.
  • Multi-language systems: With its native code generation support for a wide range of development languages, gRPC is excellent when managing connections within a polyglot environment. 
  • Real-time streaming: When real-time communication is a requirement, gRPC’s ability to manage bidirectional streaming allows your system to send and receive messages in real-time without waiting for Unary client-response communication. 
  • Low-power low-bandwidth networks: gRPC’s use of serialized Protobuf messages offers light-weight messaging, greater efficiency, and speed for bandwidth-constrained, low-power networks (especially when compared to JSON). IoT would be an example of this kind of network that could benefit from gRPC APIs.

Final Thoughts on REST vs. gRPC

Due to the various advantages of gRPC APIs that we have covered so far, some developers see gRPC as the “future.” However, these developers could be getting ahead of themselves. gRPC is not yet widely adopted, and it remains to be seen whether its benefits will spur greater adoption in the future. 

In comparison, REST is supported universally and virtually every microservices-based infrastructure depends entirely on REST APIs as the glue that holds them together. Unless your use-case demands gRPC implementation, taking the risk to adopt gRPC at this nascent stage (before widespread adoption) is neither practical nor necessary.

DreamFactory Hosted Trial Signup

Generate a full-featured,documented, and secure REST API in minutes.

Sign up for our free 14 day hosted trial to learn how.

DreamFactory: Automatically Generate REST APIs to Connect Microservices in Minutes!

REST APIs development is a vital part of developing a modern, microservices-based application architecture. However, coding a simple REST API can take weeks when you do it by hand — which represents significant labor costs and delays for your project.

This is where the DreamFactory iPaaS and API gateway can help. One of the most useful features of the DreamFactory platform is its capacity to automatically generate REST APIs. With DreamFactory, you generate a fully Swagger-documented REST API to connect virtually any database or service in minutes. 

Announcing the Launch!

Since its conception, DreamFactory has consistently provided value to its customers with its on demand, custom generated API management tools, and we’re proud of how we’ve been able to support our customers. As a result of our continued growth we have made the decision to enter into a strategic merger with some of our Xenon Partners sister companies to form launched on December 15, 2021, bringing together four companies (Xplenty, DreamFactory, FlyData and to provide a complete data integration platform. is a data warehouse integration platform designed for e-commerce. The platform allows your organization to integrate, process, and prepare data for analytics on the cloud. Because it is a code and jargon free environment, the platform allows your business to take advantage of the opportunities offered by big data without having to invest in hardware, software, or related infrastructure. 

Want to learn more about DreamFactory? Sign up for a free hosted trial now!

Related reading:

Best Developer Tools: 5 APIs That Make Life Easier for Developers