gRPC

gRPC is a system that implements traditional RPC with several optimizations. For instance, gRPC uses Protocol Buffers and HTTP 2 for data transmission.

gRPC abstracts the underlying HTTP communication. These optimizations make gRPC faster, easier to implement, and more web-friendly than other RPC implementations. 

What are the similarities between gRPC and REST?

REST and gRPC share some innate similarities as API architectural approaches.

Data exchange mechanism

Both allow two software components, a client and a server, to communicate and exchange data based on a shared set of rules. These rules apply regardless of how each software component operates internally.

HTTP-based communication

Both pass data via the HTTP request-response mechanism, the preferred efficient communication protocol of the web. However, in gRPC, this is hidden from the developer, while in REST, it’s more apparent.

Implementation flexibility

You can implement both REST and gRPC in a wide range of programming languages. This quality makes them both highly portable across programming environments. This leads to optimal interoperability with near-universal support. 

Suitability for scalable, distributed systems

Both gRPC and REST use the following:

• Asynchronous communication, so the client and server can communicate without interrupting operations

• Stateless design, so the server doesn’t have to remember the client state

This means developers can use gRPC and REST to build fault-resistant systems with a large number of concurrent requests. You can build scalable, distributed systems with multiple clients.

Architecture principles: gRPC vs. REST

While REST and gRPC offer a similar function, the underlying models differ significantly in their architecture.

Communication model

Using a REST API, a client sends a single REST API request to a server, and the server then sends a single response in reply. The client must wait for the server to respond before continuing operations. This mechanism is a request-response model and is a unary data connection (one-to-one). 

In contrast, with gRPC, a client can send one or multiple API requests to the server that may result in one or multiple replies from the server. Data connections may be unary (one-to-one), server-streaming (one-to-many), client-streaming (many-to-one), or bidirectional-streaming (many-to-many). This mechanism is a client-response communication model and is possible because gRPC is based on HTTP 2. 

Callable operations on the server

In a gRPC API, callable server operations are defined by services, also known as functions or procedures. The gRPC client invokes these functions like you would call a function internally within an application. This is known as service-oriented design. Here’s an example:

createNewOrder(customer_id, item_id, item_quantity) -> order_id

In REST, there is a limited set of HTTP request verbs that the client can use on server resources defined by a URL. The client calls the resource itself. This is known as entity-oriented design. The entity-oriented design aligns well with object-oriented programming methods. Here’s an example:

POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id

While you can design gRPC APIs in an entity-oriented approach, this is not a constraint of the system itself.

Data exchange format

With a REST API, the data structures passed between software components are typically expressed in JSON data exchange format. It is possible to pass other data formats like XML and HTML. JSON is easy to read and flexible, although it must be serialized and translated into a programming language.

In contrast, gRPC uses the Protocol Buffers (Protobuf) format by default, although it also offers native JSON support. The server defines a data structure using the Protocol Buffer interface description language (IDL) in a proto-specification file. gRPC then serializes the structure into binary format and then deserializes it to any specified programming language.

This mechanism makes it faster than using JSON, which is not compressed during transmission. Protocol Buffers are not human-readable, unlike a REST API used with JSON.