The REST API has been a pillar of .net programming for an extended time. However recently gRPC has started invading on its territory. It seems there are some excellent reasons for that. During this post, we will study the ins and outs of gRPC and the way it compares to REST.
One of the most significant variations between REST and gRPC is the format of the payload. REST messages usually contain JSON; this is often not a strict demand, and in theory, you can send anything as a response. However, to apply the full REST ecosystem, including tooling, best practices, and tutorials, it is targeted on JSON. It is safe to mention that, with only a few exceptions, REST API's accept and return JSON.
gRPC, on the opposite hand, accepts and returns Protobuf messages. I'll discuss the strong typing later, however from a performance point, Protobuf is a very efficient and compacted format. JSON, on the opposite hand, is a textual format. You'll be able to compress JSON, then again you lose the advantage of a textual format that you would expect.
HTTP 1.1 vs HTTP/2
Let's compare the transfer protocols that REST and gRPC use. REST, as mentioned earlier, depends heavily on HTTP (usually HTTP 1.1) and also the request-response model. On the opposite hand, gRPC uses the newer HTTP/2 protocol.
There are many issues that plague HTTP 1.1 that HTTP/2 fixes. Here are the main ones:
1. Latency Issues 2. The Growth of Page Size and Number of Objects 3. HTTP 1.1 Is Too Big and Complicated 4. Head of Line Blocking
How HTTP/2 Addresses the Problems
HTTP/2, which came out of Google's SPDY, maintains the basic premises of HTTP:
1. http:// and https:// URL schema 2. Resources and verbs 3. Request-response model over TCP
But the optional parts of HTTP 1.1 were removed.
Addressing the negotiating protocol thanks to the shared URL schema, there is an associated upgrade header. Also, here could be a shocker for you: the HTTP/2 protocol is binary! If you have been around web protocols, then you will recognize that textual protocols are considered the monarch because they are easier to troubleshoot and construct requests manually. But, in practice, most servers these days use encoding and compression.
However, the key improvement of HTTP/2 is that it uses multiplexed streams. One HTTP/2 TCP connection will support several bidirectional streams. These streams are often interleaved (no queuing), and multiple requests may be sent at the same time while not a requirement to create a new connection for everyone. Additionally, servers can currently push notifications to clients via the established connection (HTTP/2 push).
Serialization vs Strong Typing
The REST paradigm does not mandate any structure for the changed payload. It's generally JSON. Consumers do not have a proper mechanism to coordinate the format of requests and responses. The JSON should be serialized and reborn into the target language both on the server-side and client-side. The serialization is another step within the chain that introduces the chance of errors and performance overhead.
The gRPC service has strongly typed messages that are converted from its Protobuf representation to your selected language both on the server and on the client.
JSON, on the opposite hand, is in theory more versatile because you can send data without having to adhere to the rigid structure.
Conclusion
In the world of microservices, gRPC can become dominant soon. The performance advantages and ease of development are simply too good to pass up. However, make no mistake; REST can still be around for an extended period. It still excels for public exposed API's and backward compatibility reasons.
Note: At the time of writing this post, Azure and AWS does not support gRPC yet.
