gRPC vs. REST Interfaces, Requests and Performance
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.
gRPC vs. REST requests (+ protocol buffers)
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.
gRPC vs. REST Payload
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, Stateless Connections and gRPC-Web
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.
This can become a problem if the data set changes (adding or deleting records, for example) between 2 client requests, and is something that will always be relevant to REST architecture since it must be stateless by definition. Once again, this all comes back to the idea that gRPC is designed with the bi-directional flow of information in mind. And then there’s gRPC-Web, a JavaScript client library that allows web apps to bypass the need for an HTTP server when communicating with gRPC backends.
Definitions
REST (Representational State Transfer) 101
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:
- Stateless
- Client-Server Separation
- Cacheable
- Uniform Interface
- Layered System
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.
gRPC (gRPC remote procedure call [RPC])
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.
How to choose between REST and gRPC?
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.
