Now we are familiar with REST – as a developer, we all integrate many services through REST. For example, while we are searching about ‘” Michael Jackson “on YouTube we can have a list of videos about “Michael Jackson” REST API works in a similar way. We can search for something and getting a list of results back from the services. Developers should follow some rules while creating their APIs. REST runs over HTTP and mainly used in web APIs. JSON, XML are data formats that can be exchanged over HTTP.
REST API has been the backbone of web programming. But now gRPC encroaches over REST. For this, there are certain reasons. gRPC – a modern open-source RPC framework developed by Google (2015) and now licensed under Apache 2.0.gRPC makes it easy 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 uses 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 almost supported by all programming languages. It contains texts, commas, curly braces, double-quotes. It 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 certain situations where JSON to be used like when we want the data to be human-readable, direct consuming of data by the browser if 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 more others. The message format is simple, smaller, and faster. Protobuf have more data type than JSON. Protobuf uses a number field where JSON doesn’t. For integer encoding, double decoding Protobuf is faster than JSON. Protobuf uses keywords like required, repeated, optional are extremely powerful. We are defining services and data structures called messages in .proto formats to ensure that there is any loss of signals between applications. These files can be compiled with protocol. It is smaller and faster than XML. The currently used version of protocol buffers is proto3. It 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
Now let’s see the difference in transfer protocols. REST mainly uses HTTP 1.1 and the request-response model. gRPC uses the 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 works 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 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 bloom RPC. 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 we can conclude that both REST and gRPC will be here for so 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
Author Bio:
Anju Mohan C K: Anju works as a Software Engineer at ThinkPalm Technologies with the ETG department. Her Hobbies include Travelling and Gardening.
