Currently, almost all developers are familiar with REST and as a developer, we all integrate many services through the REST application programming interface.

By implementing the REST API, we can search for something and accumulate a list of results back from the service. It is also required that developers should follow some rules while creating their APIs because REST runs over HTTP and are mainly used in web APIs. JSON, XML are data formats that can be exchanged over HTTP.

REST API has always been the backbone of web programming but lately, we have seen a slight variation in this trend as gRPC has overstepped REST, with its innovative features.

There are certain reasons for this current overpowering of gRPC over REST, such as – gRPC is a modern open-source RPC framework developed by Google (2015) now licensed under Apache 2.0. and gRPC makes it easier to build a heterogamous distributed system.

gRPC uses standards-based HTTP/2 for long-lived, real-time communication streams. It can generate efficient client libraries in 10 different languages. It also uses a protocol buffers to define services. gRPC is the future of micro-services API and mobile server API.

Protocol Buffers vs. JSON

The main difference between REST and gRPC is the payload format. In REST we are mainly using JSON format for accepting and returning, it is a completely independent, simple, human, and machine-readable format that is almost supported by all programming languages. It contains texts, commas, curly braces, double-quotes, and even is a name-value pair.

But when we compress a JSON format we will lose the features of a textual format. In this textual format, both encoding and decoding are slower. But there are some other relevant situations where JSON can be implemented, such as, when we want the data to be human-readable, hence the direct consuming data by the browser on our server-side application is written in JavaScript.

Protocol Buffers, also known as Protobuf is Google’s efficient and automated mechanism for serializing structured data. It can be used in communications protocols, data storage, and several other functions. The message format is also simpler, smaller, and faster.

Protobuf have more data type than JSON, it uses a number field for integer encoding and double decoding. When compared on the basis of speed, Protobuf is assured to be much faster than JSON. Protobuf uses keywords such as required, repeated and optional, which are extremely powerful when communicating with a developer. In Protobuf we are defining services and data structures called messages that are generated .proto formats to ensure that there is no loss of signals between applications. It is also smaller and much faster than XML. The currently used version of protocol buffers is proto3, which supports a variety of languages including C++, Go, Java, Python, Ruby, and C#.

Defining a message in .proto file example :

//Department object

message Department

{

Int64 id = 1; – with field type, field name and field tag (integer, floating-point, Booleans, strings)

string departmentName = 2;

string location = 3;

}

gRPC’s supported languages are shown below.

 HTTP/2 vs. HTTP/1.1

Below are some of the few differences in Hyper test transfer protocols.

• REST mainly uses HTTP 1.1 and the request-response model.
• gRPC uses HTTP/2 protocol.
• HTTP/2 can fix many problems with HTTP/1.1.

Disadvantages of HTTP/1.1

• Big and complicated.
• Sensitive to latency.
• Data duplication across requests.
• Allows only one request per TCP connection.

Advantages of HTTP/2

• Multiple parallel requests can be handled using the same TCP connection.
• Reduce data redundancy.
• Header compression.
• HTTP/2 allows multiplexed streams that allow a single TCP connection to support many bidirectional streams. REST supports only the request-response model but gRPC can stream data constantly.

Types of gRPC-Service Methods :

Unary (without streaming)

Like a normal function call client sends a single request to the server and receives a single response back from the server.

E.g. service User

{

rpc createDepartment(Department) returns(ApiResponse);

}

Client Streaming

The client sends a sequence of to the server using a provided stream. When the client finished writing, it waits for the server to read all and return its response.

E.g. service User

{

rpc updateDepartment(stream Department) returns (ApiResponse);

}

Server Streaming

A streamed sequence of messages is getting back. The returned streamed messages read by the client until there are no more messages.

E.g. service User

{

rpc getDepartments(google.Protobuf.Empty) returns (stream Department){};

}

Bi-Directional Streaming

Both server and client streams work independently. Using a read-write stream they can send a sequence of messages.

E.g. service User

{

rpc updateInBatch(stream Department) returns (stream Department){};

}

The communication between a gRPC client and server is shown below.

gRPC Weaknesses

Limited Browser Support

To directly call a gRPC service from a browser is not possible so it cannot be used for external services.

Not human-readable

gRPC messages are encoded with Protobuf and its binary format that isn’t human-readable.

No URL endpoints

To check the response we can’t use postman or curl because there are no URL endpoints so we can use bloomRPC.

The performance benefits and easiness in the development of gRPC with comparing to REST will help gRPC to dominate in the world of microservices. But as of now, we can conclude that both REST and gRPC will be here for long based on their specialties on different use cases.

For a free consultation on IoT, Enterprise or Telecom Service, contact us at sales@thinkpalm.com

---