How is GRPC different from REST?

Question

I'm reading this explanation of GRPC and this diagram is of interest:

How does the transport layer work? If it's over the network... why is it called an RPC? More importantly, how is this different from REST that implements an API for the service-layer (the class in the client that has methods that make a http request)?

Answer 1

I found the image by Alex Xu, author of a famous book System Design Interviews, An Insider's Guide Volume 1 (ref https://www.google.co.in/books/edition/System_Design_Interview/TZWmzQEACAAJ?hl=en) to be a good articulation of the differences between RPC and RESTful communication protocols in his posting in LinkedIn at https://www.linkedin.com/feed/update/urn:li:activity:7062452676885630976/?utm_source=share&utm_medium=member_desktop "The two protocols differ mainly in their design philosophy. RPC enables calling remote procedures on a server as if they were local procedures, while RESTful applications are resource-based and interact with these resources via HTTP methods. When choosing between RPC and RESTful, consider your application's needs. RPC might be a better fit if you require a more action-oriented approach with custom operations, while RESTful would be a better choice if you prefer a standardized, resource-based approach that utilizes HTTP methods." The image of the comparison from ByteByteGo.comis quite good.

Three broad key differences between the two protocols (experts may please add more of key differences I am sure there are..) are (i) RESTful protocol has weak coupling, which is good from architecture perspective of the principle of "High cohesion inside a component and low coupling across components" (ii) RPC has high performance for the main reason viz. RPC uses thrift (from Facebook) or protobuf (from Google) or Avro data format which are much light weight as compared to XML, JSON formats in RESTful (iii) RESTful is more developer friendly from debugging perspective as data packages are human readable. So if you need high performance with light data loads in the communication go for RPC otherwise go for RESTful.

As mentioned by user2077221 above, one can send light weight data loads using protobuf data loads over RESTful gRPC. That's a useful point to make RESTful more advantageous overall depending on design need of the solution and the complexity of solution(using protobuf over RESTful program/method not easily available to refer & code) you want to manage.

Answer 2

Procedure call - Simple function call in the same program on the same machine.

What if this function needs to be called from outside the host computer(server)? One of the options is to build an API. If we are building API's using HTTP, we can go with one of the below two options.

• REST API's
• RPC

RPC(remote procedure call) - One program can request a service from another program located on a different computer without understanding the underlying network details. It’s a procedure call as if it’s on the same machine but it’s not on the same machine and the RPC library/framework takes care of abstracting all of that complexity.

• With REST, the client will have full access to HTTP via the HTTP client library (eg: python requests or nodejs axios). The client has to set the correct headers, set the message body, deal with serialization etc. Then there are vague and confusing RESTful/REST constraints as well like HATEOS, modelling the endpoints in certain way, etc. which becomes difficult to adhere to as the application grows.

Below example describes a client making API call to add a new book (CRUD oriented)

import requests
url = "https://www.myserver.com/api/v1/books"
body = {"book_name": "intro to c"}
x = requests.post(url, json = body)

• With RPC, the client simply calls a function (method exposed by RPC library) with required arguments as if it's a local function call. The RPC library will take care of the sending the data across the network.

Below example shows the same using RPC (Action oriented - notice the addBook() method)

import myCustomRPC as rpc
myRPC = rpc('www.myserver.com')
x = myRPC.addBook('intro to c')

RPC is a broad term that describes calling some functionality on a remote machine as if it's a local function call. There are many variants of RPC like XML-RPC, JSON-RPC, SOAP, HTTP RPC (used by slack API's), gRPC etc.

gRPC

Now if we decide to go with RPC for all our API's, we can use gRPC which is an RPC framework. In order to build gRPC service, we need to write a service definition file (protobuf definition) where services and methods are defined. Using the service definitions, we can automatically generate code (both client side and server side) in all major languages using protoc(+ gRPC plugin). The client-side code here contains methods that the API consumer can call.

gRPC supports four modes (unary, server stream, client stream, bi-directional) of communication out of the box (thanks to HTTP/2). gRPC also has pluggable features like authentication, lightweight serialization format like protobuf, tracing, client-side load balancing, health checking, timeouts etc.

"How does the transport layer work? If it's over the network?"

The API consumer or server don't have to deal with transport(HTTP or TCP) layer directly. gRPC client and server stubs abstract these details completely. Currently gRPC uses HTTP/2 over TCP and will support HTTP/3 over QUIC in the future.

Why use gRPC over REST?

gRPC is great for low latency services in the backend. Lot of popular applications now use gRPC heavily. For eg: Envoy proxy uses protobuf definitions and gRPC (for logging, discovery services, etc..)

Below from gRPC docs

Why is gRPC better/worse than REST?

gRPC largely follows HTTP semantics over HTTP/2 but we explicitly allow for full-duplex streaming. We diverge from typical REST conventions as we use static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. We have also formalized a set of errors that we believe are more directly applicable to API use cases than the HTTP status codes.

Why is gRPC better than any binary blob over HTTP/2?

This is largely what gRPC is on the wire. However gRPC is also a set of libraries that will provide higher-level features consistently across platforms that common HTTP libraries typically do not. Examples of such features include:

• interaction with flow-control at the application layer
• cascading call-cancellation
• load balancing & failover

Answer 3

The transport layer works using HTTP/2 on top of TCP/IP. It allows for lower latency (faster) connections that can take advantage of a single connection from client to server (which makes more efficient use of connection and can result in more efficient use of server resources.

HTTP/2 also supports bidirectional connectivity and asynchronous connectivity. So it is possible for the server to efficiently make contact with client to send messages (async response/notifications, etc..)

While, both REST and gRPC can generate client/server stubs (using something like swagger for REST), REST has a limited set of primary 'function' calls (or verbs):

+-----------+----------------+
| HTTP Verb |      CRUD      |
+-----------+----------------+
| POST      | Create         |
| GET       | Read           |
| PUT       | Update/Replace |
| PATCH     | Update/Modify  |
| DELETE    | Delete         |
+-----------+----------------+

whereas gRPC you can define any kind of function calls including synchronous/asynchronous, uni-direction/bidirectional(streams), etc..

Using gRPC the client makes a call to a local method. To the programmer, it looks like you're making a local call, but the underlying layer (the auto-generated client stub) sends the call to the server. To the server it looks like its method was called locally.

gRPC takes care of all the underlying plumbing and simplifies the programming paradigm. However, to some dedicated REST purists, this may seem like an over-complication. YMMV

Answer 4

I always feels gRPC and REST are absolutely two different things.

REST is best for resource oriented services. otherwise we can use gRPC for high performance.

REST is internet level, it's for end user talk with our service. gRPC is intranet level, it's for internal services talk with each other.

REST has application semantics for follow. gRPC provided nothing, you should build everything from scratch.

Answer 5

REST doesn't require JSON or HTTP/1.1

You can trivially build a RESTful service that sends protobuf messages (or whatever) over HTTP/2

You can build RESTful services that send JSON over HTTP/2

You can build RESTful services that send protobuf messages over HTTP/1.1

RESTful services are not a "hack" on top of HTTP/x.x, they are services following the fundamental architectural principals that have made any version of HTTP successful (like the cachebility of GET requests & the replayability of PUT requests).

gRPC, SOAP, et. al are more like hacks - hacks on top of HTTP to tunnel RPC-style services over HTTP, to route around firewall & middlebox restrictions. That's not necessarily a bad thing. Sometimes you might want an RPC-style service instead of a REST one, and we gotta live in a world where middleboxes are hard to replace.

If you do not have time to read up on the actual definition of REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

There's always the TLDR; version on wikipedia:

https://en.wikipedia.org/wiki/Representational_state_transfer

If you need an RPC-style service, sure, gRPC is great. If you want to live on the web, or you want all the benefits that come with a RESTful style service, then build an RESTful style service. And if it's too slow to serialize/deserialize data in JSON format in your restful service, it's perfectly OK to use protobuf or whatever.

If gRPC is a version 2 of anything, it's a version 2 of SOAP. One that isn't terrible, like SOAP.

And, no, you can't just "call any function" in your GET request, and have a RESTful service.

One last thing: if you are gonna use protobufs over a RESTful service, please do it right, using the content type headers, etc. With that, you can easily support both JSON AND protobuf.

Stepping down from my SOAP box now.. ;)

Answer 6

The biggest advantage of gRPC over REST is its support of HTTP/2 over the grandpa HTTP 1.1. Then the biggest advantage of HTTP/2 over HTTP 1.1 is, 'HTTP/2 allows the server to "push" content'...