API Battles – gRPC vs. REST

April 11, 2019

Brief History

REST – The term representational state transfer was first introduced in a doctoral dissertation by Roy Fielding in 2000, in which he explains that the REST principles were previously known as the “HTTP object model” and used to design the HTTP 1.1 and Uniform Resource Identifiers (URI) standards. REST has become incredibly popular among web developers. Many apps rely on REST for internal serialization and communication patterns. In order for an API to be RESTful, a set of constraints must be followed. These will make the API easier to use and easier to discover.

gRPC – gRPC Remote Procedure Calls was originally created at Google. It grew out of Google’s internal single general-purpose RPC infrastructure named Stubby, which connected all Google’s microservices running within and between its data centers. Stubby was reworked to extend its applicability to mobile, IoT and the Cloud and create a standardized open source infrastructure.

gRPC has become a popular framework for microservices. Within just one year of its launch, it was adopted by CoreOS, Netflix, Square and Cockroach Labs, to name a few. gRPC is also popular in telecom companies (such as Arista, Cisco and Juniper) for streaming the telemetry data and network configuration from their networking devices. Dropbox has used RPC frameworks for some time, most recently Courier, which it has extended and optimized for performance at vast scale.

Tool Type

REST (REpresentational State Transfer) is an architectural pattern or design concept with a focus on resources. Software solutions are built as collections of resources for the user to access and interact with through the use of a consistent interface.

Any information, which can be named is a resource in REST. This could be a non-virtual object, an image, a document, a collection of other resources, and so on. Originally, web resources were defined as documents or files identified by their URLs, however, they now have this much more generic and abstract definition.

REST uses a resource identifier to determine the specific resource involved in an interaction between components.

gRPC is an open source RPC framework that can run in any environment. https://grpc.io/ says the name stands for Remote Procedure Calls. One of the goals behind gRPC is to make it feel as if you are using a service on the same machine. Therefore, it requires two parties to be set up, the server as is customary and the client. “.proto” format API contracts provide a shared interface of communication between the two parties. This means the client doesn’t need to search for API documentation as it is already specified at a local level. In addition to using .proto to agree on data structures, gRPC contracts are also capable of defining types and preventing client requests from being sent together when types don’t match.

Specification, Implementation and Paradigm

All APIs conform to a paradigm, whether it’s “RPC”, “REST” or “query language”. These involve a general approach to building an API, although not a specific tool or specification. They are a concept rather than a tangible thing.

REST is a paradigm which hasn’t been turned into a specification. It has no official implementation; however, building a REST API normally simply involves the selection of appropriate standards and tooling.

gRPC, meanwhile, is an implementation, which follows the RPC paradigm. It doesn’t have a standard or specification, although Google documented the protocol.

Payload Format

The format of the payload is one of the major differences between REST and gPRC. In REST, messages usually contain JSON. This isn’t absolutely required as in theory anything can be sent as a response, however, in practice, the entire REST ecosystem (tooling, best practices, tutorials) is based on JSON.

gRPC, by contrast, accepts and returns Protocol Buffers (or Protobuf) messages, which use binary data to serialize structured data. From a performance standpoint, Protobuf is a highly efficient and packed format whereas JSON is a textual format. JSON can be compressed; however, that would lead to the loss of the benefits of a textual format. REST does offer cross-language support since all requests are handled via data-interchange formats such as JSON or XML.

Language support for gRPC is reliant upon language adoption of proto3 (the most recent version of Protocol Buffer), which supports Java, C#, C++, Python, Ruby, JavaScript and Objective-C. The serialization of transferred data in protobufs offers a significant performance boost in comparison to that of JSON or XML via REST.

Transfer Protocols

REST and gPRC also use different transfer protocols. REST depends on HTTP (most typically HTTP 1.1) and the request-response model of communication. gRPC, meanwhile, depends on the newer HTTP/2 protocol, which allows for bi-directional communication.

The improvements that HTTP/2 made to HTTP 1 are various and include:

HTTP 1.1 is large and complex
Slower page load times in HTTP 1.1
HTTP 1.1 is more sensitive to latency as a TCP handshake is necessary for each individual request
It’s harder to send multiple requests in HTTP 1.1

The most significant improvement is that HTTP/2 uses multiplexed streams – one HTTP/2 TCP connection can support many bidirectional streams, which can be interleaved meaning no queueing and multiple requests can be sent out simultaneously without the need to set up new TCP connections for each one. Servers can also now push notifications to clients via the established connection.

Ease vs. Complexity of Use

REST is built tightly on top of HTTP and embraces its features, which makes it difficult to fully implement REST. It continues to be very popular and successful, but this is partly because most implementations don’t fully adhere to its philosophy and use only part of its principles.

Nonetheless, REST prioritizes simplicity in terms of its build. It is lightweight and has straightforward URLs e.g. if you sent a DELETE request to ‘…example.com/users/10’, it would delete that data; if you sent a GET request to the same URL, it would return data related to the user with the ID 10. REST focuses on what is communicated between services as opposed to how it is communicated. HTTP verbs (such as GET, DELETE, POST, etc.) are used for requests and HTTP status codes are used for describing request statuses. However, you do have to specify headers, methods, body, etc.

By contrast, gPRC abstracts the need to specify headers, methods, body, etc. via the grpc-web-client. Furthermore, gRPC has well-defined status codes, which precisely identify what issue has occurred. gRPC also has services with clear interfaces and efficient messages for requests and responses. It borrows directly from programming language concepts such as interfaces, functions and data structures. gRPC is able to automatically generate client libraries.

Streaming vs. Request-Response

REST only supports the request-response model available in HTTP 1.1. gRPC, however, leverages the full capabilities of HTTP/2, thereby allowing for the constant streaming of information. gRPC enables several types of streaming:

Server-Side Streaming – After getting a client request message, the server sends back a stream of responses. After sending back all the responses, the server’s status details and optional trailing metadata are sent back on the server side for completion. Once it has all the server’s responses, the client completes.
Client-Side Streaming – The client sends a stream of multiple requests to the server. The server replies with a single response, usually but not necessarily after it has received all the client’s requests, in addition to its status details and optional trailing metadata.
Bidirectional Streaming -The client and the server send information to one another in free form (except that the client initiates the sequence). Ultimately, the client closes the connection.

Flexibility

REST is highly flexible. It supports various different content types from JSON to raw binary to RSS to XML. As with gRPC, REST doesn’t mind your choice of programming language.

Another positive for REST is the fact that it is stateless, meaning no client context is stored on the server between requests. This is ideal for severless solutions and reduces costs as there is no need to spend money on storage in comparison to a service that stores session states server-side.

Performance and Security

gRPC purportedly offers better performance and security than REST+JSON. Security-wise, this is because gRPC heavily endorses the use of SSL/TLS to authenticate the server and encrypt all the data exchanged between client and server. Nonetheless, REST is not going anywhere anytime soon. It excels too much at publicly exposed APIs and for backward compatibility reasons.

Conclusion

REST is used on a much more widespread basis at the moment than gRPC, and as a result has significantly more browser and language support than gRPC. gRPC is not yet widely adopted, although it is the hottest new trend. Nonetheless, REST remains the standard, which makes moving away from it potentially daunting.

REST is arguably easier to set up and many web services don’t require speed improvements by the millisecond so its relative age isn’t often a problem. However, if latency is of the utmost importance, gRPC is probably a better choice of communication protocol. Perhaps the best use for gRPC currently is the development of new microservices in which speed and scalability are of the utmost importance.

Programmer Phil Sturgeon also says an important area to take into context when making a choice of paradigm is “bounded context”. When a developer or development team is involved in clients and servers, but not in close communication, layers of abstraction become highly useful. REST, for instance, allows for pushing client-side validation to JSON Schema; it is also possible to push workflows and resource state to the API as opposed to having RPC clients attempt to work it out by looking at random properties.

Further Resources

REST Tooling: