When the conversation turns to APIs and architectural styles, gRPC and REST are two acronyms that are bound to come up.
The ‘R’ in gRPC doesn’t, however, refer to REST, with the former acronym standing for gRPC Remote Procedure Call. Not Google Remote Procedure Call, as you might think, but we’ll get to that below...In any case, that doesn’t tell you a whole lot about what gRPC actually does. Most people in the API space have some familiarity with REST, with RESTful development being the most prevalent type of architecture by far in 2021. In comparison, Google’s gRPC is a relative newbie to the scene that first debuted in 2016. Because both styles communicate over HTTP, gRPC and REST share some similarities. But they’re definitely not the same thing. On this page we’ll be covering exactly what gRPC is, and what it’s used for, as well as how it differs from REST.
REST is not a protocol, but a concept that many of the best APIs follow. APIs that conform to all, or almost all depending on how strict you’re being, of the tenets of REST architecture are known as RESTful. Those tenets are as follows:
First defined in the year 2000 by Roy Fielding, REST has evolved a lot since then. For example, many API developers will now pick and choose which aspects they follow to create REST-ish or REST-like services. Services that follow the REST architectural style differ tremendously because, even though there are best practices and standards associated with REST APIs, it offers a ton of flexibility and few restrictions. Since it’s platform agnostic, for every very familiar Python RESTful API you encounter, you might run into some other more obscure service. It’s all based on the client-server principle: the server waits for a connection and the client connects to it to get data or send commands. It’s a process that even non-technical users will recognize from retrieving web pages, submitting a contact form, downloading files etc.
Created by Google in 2015, it’s not surprising that many people think the ‘g’ in gRPC stands for Google. The use of the lowercase ‘g’ in the acronym, however, should be a big clue that this is not the case. Confusingly enough, the ‘g’ in gRPC actually stands for…gRPC. It really isn’t worth losing sleep over this, however, as this lowercase ‘g’ is just here to indicate that this is a specific variant of RPC architecture; an open source system used to make remote procedure calls.
RPC allows users to execute a subroutine of a program in another space, either on the same physical machine in virtual spaces or on another machine through a network. gRPC can be seen as an extension of RPC that works on HTTP, so it's exclusively network-oriented. Again, gRPC is agnostic when it comes to platforms and programming languages so you might encounter gRPC Python microservices, gRPC Node apps, C# gRPC services, and various other different languages being used in such web services.
At their core, REST services are all about defining methods of communication and access to resources on the web. That starts with a web address, using HTTP protocol or HTTPS, that contains the address of a server (and possibly a path) as well as parameters to personalize actions or provide authentication data. HTTP verbs – PUT, GET, POST, PATCH, DELETE – indicate the kind of action that will be executed on the server. The same URL can have different actions depending on the verb being used. Let’s look at a quick REST API example: you could use GET on https://myserver/users to obtain a list of users, or POST (commonly used by web forms) to create a new user with the same address.
Headers can also be used to store data sent with POST, PUT or PATCH requests, whereas data is part of the URL for GET and DELETE. They also allow the passing of additional fields, which are sometimes used with tokens for authentication. Like REST, gRPC’s HTTP/2 setup involves a web address in conjunction with HTTPS/HTTP protocol, a server name or IP address, and a path similar to REST. It also uses service definitions that define the structure of the object, which both interfaces understand and can exchange. It uses protocol buffers* by default, an interface definition language (IDL) for describing the service interface and the structure of payload messages. *We’ll get into protocol buffers in more detail below.
REST and gRPC both facilitate connections between two interfaces: client and server. The server interface is often called an endpoint. The connection is established for a specific goal, e.g. retrieving a particular set of data or sending a remote command. Opening a connection is called making a request and, when data needs to be sent in one direction or the other, it’s called a payload.
The payload is a packet of data containing what’s sent by one interface to another. Note that a payload can be sent by the interface initiating the connection, by the other, or by both. It’s worth highlighting here that some gRPC vs REST API testing found gRPC example transmissions to be much quicker – 7 to 10 times, according to coder Ruwan Fernando – than REST, which is great for real-time communication. However, the widespread support and tutorials available for the ubiquitous REST, such as OpenAPI spec and Swagger tools, means that actually implementing gRPC might take longer.
In the case of REST API design, it’s up to programmers to set up request details. In most cases, that means using a library that provides tools to make connections over HTTP 1.1, send requests, and get responses. With third-party APIs some libraries take care of retrieving the input parameters; internally building the payload, establishing a connection, waiting for a response and then providing it as output.
gRPC, on the other hand, uses protocol buffers by default. Here, the developer will use an object that takes care of payload generation, encryption, sending, and buffering. They don’t need to write corresponding tools or download libraries, just define the protocol (payload structure). The key difference here is that, even though contrary mechanisms exist, REST is built for clients to request a server in a unidirectional fashion while gRPC is meant for bidirectional streaming of information between a client and server.
With REST, no specification is defined. The developer is responsible for defining the data type and the payload structure, with JSON used in most cases. Both the client and server must pay close attention to its structure and content; the payload created by the client must have the same structure expected by the server, or it won’t be able to read it.
In addition to setting up these mechanisms, REST relies on the developer to ensure security. If not implemented by the developer, data will travel on the network without any particular encoding. In most cases, security relies on the use of the HTTPS protocol. gRPC recommends the use of protocol buffers, which define the structure of the payload. This makes it easier to define the data structure on both the client and server sides. gRPC also encodes the content of payloads between the client and server, which provides an extra layer of security on top of using HTTPS.
REST depends on developers setting up an authentication system – it’s up to them to set up the mechanisms to authenticate themselves to the servers at each request in a secure way. Because REST is stateless, which means that each connection is decoupled from the next, every request must go through the authentication mechanism. gRPC, on the other hand, integrates an authentication mechanism with multiple ways to customize it.
One of the problems associated with REST being stateless is that it is the responsibility of programmers to implement mechanisms that allow different requests to ensure continuation. For example, let’s say that a client requests a very large set of data from a server. If the server breaks the answer into pages – similar to the way Google displays search results on different pages – then the developer has to implement a mechanism that allows data consistency between pages.
There are a few different things to consider when choosing between REST and gRPC, but one of the most important is market penetration. Most API developers know how to use REST, more so than gRPC, so it’s easy to find programmers that already understand it and are adept at code generation.
That said, gRPC is fairly easy to learn so the shallow learning curve won’t put you off training staff to use it. Plus, gRPC provides a clear model with a structured message to enforce good practices. That isn’t necessarily true of REST, the concepts of which are not always fully respected by developers...and that’s putting it mildly. If you need to establish long-lasting connections with streaming and the bi-directional exchange of data between interfaces, gRPC is a clear winner. However, if web browsers are used to access your software, support for gRPC is minimal; it’s intended to be used for API and inter-system communications, not for client-side browser consumption by end-users.
We’ve already touched on speed above, but it can be argued that gRPC is safer than REST too because the former integrates authentication mechanisms. In the REST world, developers have to create their own and there’s a risk of errors associated with that. Will the idea of the gRPC API grow to unseat REST in the same way that the latter did to SOAP? That remains to be seen, but we’re definitely not there yet. For the time being, in most API use cases, REST remains the king.