REST vs gRPC

Application Program Interface(API) is a set of definitions and protocols that allow technology products and services to communicate with each other. In simpler words, it’s just set of functions where you can call it by giving an request and it will perform a set of operations and it will return you a response.

The REST API’s has been one of the important aspect of web programming. It’s been a bridge between the front-end and the back-end. In most of our applications we use REST API’s to communicate between the UI and the Database. But recently gRPC has started to build their territory towards the API’s.

In this blog , we will explore about REST and gRPC and finally we will compare both of these techniques to choose the best one.

REST API

REpresentation State Transfer(REST) is an architectural style for distributed hypermedia systems. It was first presented by Roy Fielding in 2000. Most of the companies started to build their API’s in REST pattern.

Like any other architectural style, it has it’s own 6 guiding constraints which must be satisfied by an interface.

• Client-Server
• Stateless
• Cacheable
• Uniform interface
• Layered System
• Code on Demand

REST API’s work on top of HTTP layer such that you can use methods such as GET, PUT, POST, UPDATE, DELETE etc.

Since it uses HTTP layer, the REST API’s are stateless and whenever a request sent to REST API it should contain all the information such that it can perform some operations and give you an appropriate response.

gRPC

gRPC is an open-source Remote Procedure Call System initially developed by Google on 2015. And also gRPC methods can run on any environments. You don’t have to worry about the request and response model, since it uses protobuf messages.

As you see gRPC Server is created using C++ and it will seamlessly communicate with other programming languages such as Ruby, Android etc. All the request and response should be defined as Protobuff.

REST vs gRPC

Let us compare REST over gRPC and see which would be the right choice to build our API’s.

HTTP/2 vs HTTP 1.1

gRPC uses HTTP/2 transfer protocol which is an binary protocol. Basically most of the internet protocols are textual protocols that can be easier to humans to troubleshoot since it’s an binary protocol it would be more secure. And also it uses multiplexed streams and a single HTTP/2 TCP connection can support many bidirectional streams.

REST uses HTTP 1.1 and it strongly dependent on request-response model. But there are several problems in HTTP 1.1. It’s too big and complicated and since our web page sizes are growing each object in the respective page should need an TCP connection which slows down the performance of the web page.

Protobuf vs JSON

gRPC uses Protobuf as the format of the payload. From the perfomance point of view, Protobuf is very effficient than JSON and also it will be in an packed format.

//Protobuf message
message SearchRequest{
       string query = 1;
      int page_number = 2;
}

REST uses JSON as the format of the payload. Bascially you can send anything as a request and in return it can send anything as a response. But in the REST world, most of them uses JSON. It’s an textual format and also you can’t compress a JSON. And also sometimes your JSON structure gets too much complicated.

Streaming vs Request-Response

gRPC supports all kind of streaming such as Server-Side streaming, Client-Side streaming and also Bidirectional Streaming. As you see, client can send a stream of requests to server as well as server can send a stream of response. It makes gRPC more powerful.

REST since it’s fully dependent on HTTP 1.x, it supports only request–response model.

Strong Typing vs Serialization

gRPC service contract has strongly typed messages such that it will take care of converting the protobuff representation to your respective programming language. Yea I know this sounds awesome.

But in the REST paradigm, it’s only JSON, even if you use any other language you need to serialize your request to JSON and you need to send it to the server and the same applies for server to client.

Client Libraries

gRPC uses an conceptual model to have services with interfaces and functions and request-response structured messages. It allows gRPC to automatically generate the client libraries for you.

But whenever you use REST, you need to create client libraries based on that API’s and you can use it for further operations.

Conclusion

There are lot of advantages of using REST but gRPC covers most of the cons of REST and it’s been performing well than REST. gRPC provides,

• High performance along with Safety
• Duplex streaming
• Selective message compression
• Auto generated client code
• Heavily optimized
• Create Connection Pool

gRPC will rule the world of API’s in the future and also it has some pain points such as you cannot test this using url’s and also there are no predefined status codes. But you know, there are less number of cons when comapared to REST.

So my suggestion would be, if you are going to create a new project, use gRPC rather than REST.

In our next blog we will explore about Microsoft Azure.

Happy Coding!

Cheers! 🙂