REST is the golden standard of web APIs. With them, developers can quickly set up a web server that can then share information with every web browser that connects to it. Because of their ubiquity in web development, REST APIs are also frequently used in other places such as mobile applications and microservices. 

However, REST is not always the best choice. When you’re working with multiple backend services—each of which is in your own control—there are much more efficient solutions out there. One of these is gRPC, a popular remote procedure call framework created by Google for organizing microservices. 

In this article, you’ll see how REST compares with gRPC. By the end, you’ll understand situations where it’s better for you to upgrade to gRPC as well as those where it’s preferable to stay with a simple REST API and not over-engineer your solution. 

Differences between REST and gRPC

To start, it’s important to acknowledge that REST is an architectural style, while gRPC is a framework that is a concrete implementation of another architectural style—RPC (remote procedure call). 

This means that you have a lot of freedom on how to build your REST API, while a lot of things are already taken care of for you if you decide to use gRPC. To be able to compare the two, this article assumes a classic REST HTTP API such as is frequently used in basic web apps.

Underlying protocol

Both REST APIs and gRPC use the HTTP protocol. HTTP has two major versions: HTTP/1.1 and HTTP/2. 

Due to REST being a style and not a framework, developers can use either of these versions for their API. It’s much more common to use HTTP/1.1, though. gRPC, on the other hand, currently uses HTTP/2.

Data in HTTP/2 is exchanged as compressed binaries and not as human-readable text, which decreases the size of messages. HTTP/2 also supports things like multiplexing (sending multiple streams of signals over one channel) and streaming (both one-directional and bi-directional). Multiplexing gives efficiency benefits: you don’t need to open six-plus TCP connections to download one web page. 

gRPC isn’t tied to any particular version of HTTP protocol, so it will be possible for users of gRPC to quickly upgrade to other versions of HTTP when necessary. In fact, users don’t encounter the finer details of HTTP at all when using gRPC—the framework takes care of all of that behind the scenes. 

Meanwhile, the semantics of REST are strongly tied to the semantics of HTTP methods like GET, POST, etc. If you want to achieve something that is not covered by these, it’s usually a bit awkward to express.

Data exchange format

REST doesn’t have a prescribed data format to represent resources. The one that is most commonly used is JSON, which is an untyped, text-based format. Other formats such as XML and even HTML can be used. 

In contrast, gRPC uses protocol buffers (protobufs) by default. These define both the interface of the service (which methods can be called) and the structure of the messages returned.

Serialization and typing 

As mentioned before, the most common message format for a REST API is JSON, while for gRPC it is protocol buffers. But programming languages can’t directly use messages in these formats.

When you process a JSON file on the server, you have a language-specific representation of JSON, such as a Python dictionary. To send it, you need to convert it to JSON. Then, when the receiver gets JSON, they need to process it. To do that, they need to convert it back to a language-specific representation in the language that’s used by the client—for example, a JavaScript object. These processes are called serialization and deserialization, respectively. 

The languages used on the server and client side can be different, which is why message formats are useful. But due to JSON being untyped, the existence of certain fields and the contents of those fields is not guaranteed. For example, you might receive a message with a field called “address”, but no one is prohibited from accidentally putting a number there. 

Protocol buffers, the gRPC data exchange format, cannot escape from needing to serialize and deserialize data to send messages. But the format is typed, which adds extra safety. Additionally, all the client libraries are worked on by Google, which means it’s much more likely that messages sent via protobufs will be interpreted the same by clients in different languages.

Resources vs. actions 

In REST, a client requests information about a resource. The semantics of this is extremely clear and easy to use when all you have is a web server talking to a browser, and all you’re doing with it is returning information about specific items like t-shirts in a store or posts on a discussion board. 

In gRPC (and other variants of RPC), a client requests an action (procedure call) to be executed. An action can return information about a specific item, but it can also do much more: send events, subscribe to streams, manage tasks, etc.

While REST and HTTP method semantics can be used to simulate most of these actions, it’s in no way clear or convenient.  

Browser support

REST, as the standard web API, works well with all internet browsers. If you have a classic REST API that uses JSON, you will have no difficulty requesting information in a browser and showing it on a browser.

In contrast, it’s not possible to implement a full gRPC client in the browser due to the fact that browsers currently don’t provide powerful enough tools for working with HTTP/2 features. So a browser cannot talk with a gRPC server directly. 

If you want to use a web client as a part of a system that has gRPC servers, you can use a grpc-web client in combination with a proxy like Envoy. The communication with the proxy will happen in regular HTTP, and the proxy will translate the requests to gRPC. Alternatively, you can put a REST server in front of the gRPC server that web clients can connect to. 

Both of the solutions above are a bit awkward, so it’s better not to use gRPC if all you need is a simple client-server architecture for a web application. 

Language support 

There is a web server client that can implement a REST API in virtually any programming language that you’ll encounter. 

In contrast, gRPC officially supports only a certain set of languages. While the set is sizable, it is missing some rather popular languages like Rust and Elixir, which can be reasonable choices for building efficient microservices, for example. 

If many of your microservices are in a language that gRPC doesn’t support, you won’t be able to use the main benefits of gRPC such as code generation. In fact, you might end up doing much more work than with setting a regular REST API. 

Differences in response size

Due to most REST APIs using HTTP/1.1, their response size is much bigger than gRPC’s. In HTTP/1.1, the message format is human-readable text and not a compressed binary. So, the message size is much bigger than it could be with HTTP/2 (which is used by gRPC), where messages are compressed into binary frames.

You can find an excellent breakdown of the differences in efficiency between HTTP/1.1 and HTTP/2 in this article by Cloudflare.

Additionally, even if you upgrade your REST API to HTTP/2, it still might not be as efficient as gRPC. That’s because the framework has a lot of additional code that uses HTTP/2 features in an efficient and battle-tested way. And messages in protocol buffer format serialize better than messages in JSON, so they will be smaller by default. 

Speed differences

Due to the messages being smaller (as covered in the previous section) and a more efficient use of TCP channels (because of multiplexing, you need to open only one channel between client and server), gRPC should function faster than REST. 

Conclusion

This article covered two popular ways of building APIs: REST and gRPC. Each of these are better fit for certain use cases.

REST is a great solution for simple, resource-oriented web APIs because of ease of use, simplicity, and web browser support. gRPC should be your framework of choice if you need an efficient API for communication between different backend services. In this case, the control you have over the consumers of your services enables you to get all the benefits of gRPC while avoiding the web browser support problem.

Cerbos —a self-hosted, open source authorization layer—picked gRPC for performance reasons. Authorization is in the critical path of every request, and therefore needs to be as fast as possible as it can’t be cached like authentication.