REST and gRPC are nearly ubiquitous at this point. Often presented as two competing offerings, they are actually two very different modalities. Understanding their benefits and drawbacks is crucial to any developer beginning their journey in this space. Today, we’ll briefly examine the two options and define some general advantages and disadvantages of each.

What is REST?

REST, or Representational State Transfer, is a set of architectural constraints created by Roy Fielding to define data interaction and manipulation. In this paradigm, data interaction and manipulation are stateless, meaning that the server does not store the state of the client session on the server side. This statelessness means there is no need for servers to hold sessions for the end user, allowing APIs to grow to millions of concurrent users without onerous synchronization logic or large client state caching.

REST APIs typically use the HTTP protocol to interact with data through URI endpoints. Once a request is made to a resource owner, a representational state of that date is returned, representing the data’s current state and the response to client CRUD requests (e.g., GET, PUT, POST).

Notably, to be RESTful, a set of constraints must be met:

• • Client-Server: REST applications must contain a server that manages application data and defines its state. The server interacts with a client that interfaces with user interactions. Each of these components is independent and can be modified independently.
  • Stateless: REST applications must be stateless. All of the state data are managed from the client side. A request from the application contains all of the information necessary for their processing.
  • Cacheable: REST servers mark their data as cacheable or not. This lets clients and infrastructures decide if they want to cache information or not to improve performance. It also enables them to dispose of non-cacheable information, so the data they receive is guaranteed to be fresh and relevant.
  • Uniform Interface: Having a uniform interface may be REST’s most defining characteristic. Fielding states, “The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.”

• Layered System: Components of a REST system cannot see beyond their layer. This makes it easier to add additional levels of security and load-balancing for enhanced performance.

What is gRPC?

gRPC, or gRPC Remote Procedure Call, is a cross-platform open-source framework based around the concept of calling procedures on an external system from a remote location. In essence, every function on a system can be considered a procedure — when a user utilizes an API to request this procedure be run, we call this a remote procedure call.

gRPC is Google’s framework to allow these remote procedure calls utilizing something called protobufs. A protobuf, or Protocol Buffer, is essentially an interface description language, representing the contract and understanding required for different languages and frameworks to issue a request for a procedure. By utilizing protobufs over HTTP/2, gRPC, in theory, allows any system to make a remote procedure call, regardless of implementation, language, or process, assuming it correctly implements the protobuf itself.

Notably, the HTTP framework is not a paradigm as in REST, and is instead a specific framework that is controlled and iterated upon by Google and its partners.

Advantages of REST and gRPC

Firstly, it should be noted that REST and gRPC are fundamentally different approaches to the same end-user issue — interacting with remote systems. Whereas RESTful systems are more concerned with data representation for the end user, gRPC is more concerned with surfacing the actual remote procedures. In essence, gRPC and REST may look the same to the end user, but they function fundamentally differently.

This creates some balances that are important to consider when implementing either technology. First, it should be considered that REST is not a hard and fast rule. In many cases, its implementation flexibility can be either a weakness or a strength. gRPC is very specific about how you implement it as a framework, and as such, there’s not really a major difference between gRPC implementations. This removes some control from the developer but results in a continuity of provision for the end developer and end user, which is a potential strength.

REST, on the other hand, is very broad in application. Yes, there are RESTful constraints, but many implementations differ wildly from each other while still technically being RESTful. In this way, REST is a far more flexible implementation. This flexibility comes with the aforementioned cost, however. Two RESTful implementations may differ wildly while still technically being RESTful.

While REST and gRPC implementations have some variance in terms of payload, complexity, and so forth, we can also make some general statements for pros and cons. gRPC is entirely contract-based and, as such, is much more useful when implementing systems defined by business operations, specific functionality, and limited use cases. REST is much more flexible, surfacing the data to the user with a shoulder-shrug response to what the user can do with it.

gRPC has one major strength over REST that is notable. Since gRPC is bidirectional, and REST is specifically client-server, the streaming modality allows for closer coordination, mirroring complex functionality and systems with a client at a much higher level. This, paired with the pure speed of HTTP/2, means that users who want procedure call functionality upon data rather than just the data itself (for instance, in thin client and IoT situations) benefit greatly.

REST, on the other hand, boasts a major benefit in the fact that it has strong browser support. Because the implementation of HTTP/2 for gRPC is rather complex, REST is technically the only one of the two with any amount of browser support, and this fact alone may make gRPC a non-starter for certain use cases.

Finally, gRPC and REST represent two very different modalities of definition and consumption. It’s important to remember that gRPC is relatively new, having been released in 2015. Originally developed and open-sourced by Google, it’s now a CNCF incubation project. REST is older, having been defined in 2000, and is an open pattern. These points are neither here nor there regarding benefits or drawbacks, but they are important distinctions to consider.

Conclusion

Ultimately, the argument between gRPC and REST is one between competing modalities. While the end result will look very similar to the end user, their makeup and approaches are very different, and it is up to the individual developer to figure out what benefits they desire and what drawbacks they can tolerate.

What do you think of this comparison? Did we miss anything? Let us know in the comments below!