gRPC vs. REST

In the great atlas of the internet, application programming interfaces (APIs) are the roadways that connect cities, towns, beaches and other destinations. APIs enable software applications to communicate with each other to exchange data, features and functionality. A 2023 Imperva report found that about 71% of internet traffic consisted of API calls, showing just how vital this technology is to the working of modern applications and enterprises.

It’s no wonder that understanding how to build an API is a fundamental skill for most developers. But, as befits such an important infrastructure, there are multiple varieties.

To extend our metaphor, a 12-lane superhighway isn’t “better” than a single-lane surface road; that superhighway would destroy the fabric of an urban neighborhood and that surface road would be a disaster in a high-traffic area. Different architectural styles for building APIs, such as REST and gRPC, are the same way: each has strengths and weaknesses and understanding those strengths and weaknesses is vital to the creation of a healthy infrastructure.

Representational State Transfer, or REST, is a set of design principles (or architectural constraints): uniform interface, client-server decoupling, statelessness, cacheability, layered system architecture and code on demand (optional). APIs built using these principles are called REST APIs, or RESTful APIs.

REST APIs can use various programming languages and data formats, provided they conform to REST principles. It’s the most common way to construct an API.

REST APIs use HTTP requests (also known as HTTP methods) such as GET, POST, PUT and DELETE to perform standard database functions. These operations are used for creating, reading, updating and deleting resource records and are often referred to as “CRUD.” Server-side resources are identified by URLs called endpoints.

For example, a REST API would use a GET request to retrieve a record. A POST request creates a new record. A PUT request updates a record and a DELETE request deletes one. All HTTP methods can be used in API calls. A well-designed REST API is like a website running in a web browser with built-in HTTP functionality.

Resource information can be delivered to a client in many messaging formats including JavaScript Object Notation (JSON), HTML, XLT, Python, PHP or plain text. JSON is popular because it is both human and machine-readable and programming language agnostic.

Learn more about REST vs. GraphQL

Browser support: Because REST APIs use HTTP/1.1 and standard HTTP methods, as well as formats such as XML and JSON, it is compatible with browsers. 

Ease of use: Owing to its simplicity and popularity, REST is widely viewed to be easier to understand, especially for beginners. Tools, tutorials and guides are plentiful on GitHub and elsewhere.

Flexibility: REST APIs are considered to have loose coupling between client and server. This flexibility enables simpler, quicker changes: a change can be made to either side without requiring a change to the other.

Robust ecosystem: REST APIs have a significant number of tools and broad support and documentation. The OpenAPI Specification, or OAS, for example, provides an industry standard definition of a REST API’s parameters and capabilities. The latest version of OAS, OAS 3.1, includes full compatibility with JSON Schema, standardized identification that uses the SPDX identifier and more.

Reliance on HTTP/1.1: While REST’s use of HTTP/1.1 gives it universal browser support and some customization in headers, it also deprives REST APIs of some of the benefits of the newer HTTP/2. Those missing benefits include bidirectional streaming; REST supports only unary streaming, in which one request is followed by one response.

Slower and less efficient: As with HTTP/1.1, REST’s reliance on formats such as XML and JSON come with drawbacks as well as benefits. Those formats are human-readable, which is nice, but they are also comparatively large files, which means slower transmission.

Requires extra tools: REST’s ecosystem might be robust, but it needs to be, as some features are not built into the architecture. Code generation, for example, is available in the form of plug-ins for REST, but that’s still an extra step, with extra complication.

gRPC is an open source framework that Google initially developed as a specific implementation of remote procedure call, or RPC. It is now managed by the Cloud Native Computing Foundation (CNCF).

gRPC might or might not stand for “Google Remote Procedure Call,” as the developers cheekily insist that it might instead stand for “gRPC Remote Procedure Call,” or various other possibilities. In any case, gRPC—like other RPCs—enables remote calls to appear and function as local calls.

As a model for client/server interaction, RPC is often used in API development. In an RPC model, the client interacts with an intermediary commonly referred to as a stub. This stub converts data for transmission and, once it receives the requested results from the server, converts it back to the original format for the client. There are many different types of RPC frameworks including XML-RPC and JSON-RPC.

These RPC frameworks are lightweight, relatively simple to use and provide benefits such as simplified development and network communication abstraction. However, environments like microservices architectures and systems with high data loads often require a higher performance framework and gRPC was developed to meet that need.

gRPC uses an interface definition language (IDL) called Protocol Buffers (Protobuf) to serialize structured data into binary. Since binary is more compact than JSON or XML, this enables the transfer of larger payloads at faster speeds.

gRPC also uses HTTP/2, which enables bidirectional streaming and makes gRPC a strong choice for APIs in distributed environments (particularly those that require real-time communication), microservices architectures, streaming applications and the connection of Internet of Things (IoT) devices.

Speed: gRPC, through Protobuf, serializes and deserializes data from many different languages, including Java, Python, Ruby and more, into a binary payload for transmission. This code is lightweight, so transmission time and latency in data exchange are reduced with gRPC APIs.

Code generation: gRPC includes a Protobuf compiler called [protoc], which offers native code generation features. Once data structure is defined in a .proto file, gRPC can generate both client- and server-side code.

HTTP/2 support: Relying on the HTTP/2 transport protocol, gRPC supports various types of streaming. For example, it supports bidirectional streaming, in which the client and server can independently send messages in a read/write stream, in addition to client-side and server-side streaming.

Interceptors: gRPC supports middleware known as interceptors, which allow for increased functionality. Interceptors can be installed to implement security, authentication, metrics analysis and more.

Cancellation and timeouts: gRPC supports cancellation, otherwise known as timeouts or deadlines: a specified time after which the call will be cancelled.

Novelty and the ecosystem: While gRPC does include extra features such as code generation, it is a relatively new architecture, having only seen its initial release in 2016. That newness has left the documentation and support limited when compared with older architectural styles.

Steep learning curve: Some developers find gRPC to have a steeper learning curve compared to REST. Its binary data serialization provides for efficient communication, but is not human-readable.

Lack of browser support: Because web browsers do not natively support the gRPC protocol, it is not possible to directly call a gRPC service from a browser-based application One way to work around this issue is by using a proxy such as gRPC-Web. gRPC-Web essentially acts as a translation layer between a browser’s HTTP and gRPC protocol.

REST and gRPC have many elements in common and are both used to build scalable systems. Similarities include:

Client/server architecture: gRPC and REST are both client/server architectures with a request-response format that enable a client and server to communicate and exchange data. In this architecture, a client sends a request and the server responds by returning requesting data or performing a requested action.

Platform-independent: gRPC and REST enable services built on differnet platforms with different operating systems to communicate.

Statelessness: Both REST and gRPC are considered stateless, meaning that each request includes all information required to complete it. The server does not need to store any information on previous requests.

Language support: Both architectural styles are language agnostic, meaning that these APIs can be used by applications written in various programming languages. This quality makes both portable across programming environments.

Use of HTTP: Both REST and gRPC rely on HTTP-based communication. However, gRPC uses HTTP/2, whereas REST relies on HTTP/1.1. Also, gRPC abstracts the underlying HTTP/2 communication protocol, while HTTP communication is less abstracted in REST.

The key differences between REST and gRPC can help developers decide which is best for the API they are building. Those differences include:

Data format: REST APIs primarily use text-based formats such as JSON and XML. gRPC uses Protobuf to encode data into binary format.

Communication pattern: REST supports only unary communication, meaning one request followed by one response. gRPC supports others, including bidirectional streaming (both client and server exchange independently), server streaming (a single request triggers multiple responses) and client streaming (multiple requests result in a single response).

Design pattern: gRPC has a service-oriented design, in which callable server operations are defined as services or functions. In REST, design is oriented around resources, in which HTTP methods are used to access server resources through endpoints defined by URLs.

Coupling: gRPC’s client and server are tightly coupled, meaning that both the client and server must have access to the same middleware proto file. Any change in one requires a change in the other. REST is loosely coupled. This independence means that changes in one component do not affect the other.

Code generation: gRPC offers built-in code generation; REST does not, though there are plug-ins available.

Implementation: REST requires no specific software and indeed supports browsers. gRPC requires specific software on both the server and client sides.

REST is a popular API design choice for a reason; its simplicity, wide compatibility and versatility make it an excellent choice for many applications. For public APIs, REST is often the more sensible choice, as it is more widely used and often more easily understood. Many developers are more familiar with REST and might have significant infrastructure specifically for REST, including servers, API management tools, dev tools and various testing tools.

REST also supports built-in caching, or the ability to store frequently accessed data, whether that’s locally or via a proxy. Caching can significantly improve speed and efficiency, though it also needs to include various validation, authentication and expiration information.

REST is also generally preferred for web services and web APIs, owing to its support for HTTP/1.1 and its universal browser support. It is generally preferable to gRPC for simpler data communications. Its loose coupling and reduced complexity can improve the scalability of system architecture and can help make an environment more flexible over time. However, this adaptibility comes at a performance cost. 

gRPC is a relatively newer architecture, with developers increasingly embracing its speed, efficiency and built-in tools. It is often used for real-time streaming applications and complex APIs that require high performance and the handling of high data loads in distributed systems. While more complex than REST, the use of HTTP/2 and Protobuf give gRPC greater performance scalability. 

gRPC is well-suited for microservices architectures, as its ability to stream bidirectional data in real time allows for the different services within an application to send and receive concurrently and independently. It’s also seeing support in mobile applications due to its fast, compact data transmission and because mobile applications are less likely to rely on a browser.

gRPC is also ideal for connecting IoT items to backend APIs, because its compact payloads, low latency and high-performance efficiency plays well with low-power technology.