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)?

Runion

«If it's over the network... why is it called an RPC» — Because RPC is a Remote Procedure Call, and 'remote' can totally mean 'on another host'. – Retractor

whereas rest does not mean on another host? – Runion

Neither require network / remote host, and neither rule it out, as both are oblivious of where the client / server is located. It's a concern of transport layer. – Retractor

A big difference also is in communication mode ( Unary, streaming ) , you can use Bidirectional Communication, in other word you can send a message to the client, Rest cant do that. – Godless

Answer 1

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

Tauto

So, quick question: In REST, you can also kind of call any kind of function. For example, in Rails, I can send a GET request to an endpoint that is non-RESTful and do something besides just obtain a resource. I can kick of really any function from that non-RESTful endpoint. I can also create services in REST that appear to be calling a local method but really under the hood is making a http call to an endpoint. So the differences aren't that great are they... at least on the transport layer. Or are they? – Runion

REST/RESTful runs over HTTP, gRPC runs over HTTP/2 (like a WebSocket). Using a code generator from Swagger it is possible to generate client and server stubs for REST, gRPC uses a proto file to generate it's stubs (not unlike the old WSDL/SOAP approach). The proto file defines type, so the generated client/server stubs are type safe. On a mobile device the gRPC connection is efficient as it can share the same underlying HTTP/2 socket with any other concurrent connections from the mobile app. – Tauto

Here is a nice intro to gRPC: medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b Here is a demo of gRPC: github.com/mmcc007/go – Tauto

@Tauto Nice explanation. What happens in case of REST with HTTP/2 vs gRPC with HTTP/2. Do you still think, gRPC is faster in terms of latency and network throughput? – Jerid

LakshmanDiwaakar: I see you asked the question over here. – Teenateenage

Jwan622 and mmccabe: Using the Superglue 2.1 library, I can build a house with apples and oranges. At some point, we have to choose the right tool for the job and always seek to minimize the complexity of our software system. Remember, removing code is always a performance optimization ;) – Teenateenage

From my perspective, stuff like RESTful APIs has always been a "hack" to ride along on old protocols. If something comes along which lets me use a stack more suitable for modern languages and still be agnostic to which language specifically is being used by a client AND increase performance dramatically, then I am going to be the first person to jump on the bandwagon! – Teenateenage

@MartinAndersson What is that solution, especially for big data calls, possibly streaming? – Procrustean

@Tauto You mentioned "The transport layer works using HTTP/2 on top of TCP/IP... " which isn't specific to grpc; but even REST could be exposed over HTTP/2 and nowadays people are already doing it with the rise of HTTP/2. I don't see how the first part of your response differentiates grpc from rest. Even it should be noted that the "lower latency (faster)" thing about HTTP/2 could be applicable for both; not only grpc. – Polito

@Polito The comment is not necessarily specific to gRPC but rather in answer to the question 'How does the transport layer work?'. gRPC can work natively with HTTP/2 which is implemented as a web socket that supports socket re-usability (for improved latency), multiplexing and bidirectionality. REST does not take advantage of these features of HTTP/2. – Tauto

just curious why POST not mentioned as primary 'function' calls? – Gunn

@Lei Yang: Good catch... wow, never noticed until now!... added the POST – Tauto

Answer 2

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.. ;)

Aceae

Are you implying that a RESTful service can't be created using gRPC? – Allomerism

The RTFM citing Fielding's dissertation was overkill, but otherwise great response. – Thetisa

Answer 3

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'...

Saporific

Server push doesn't need HTTP/2. – Orientation

Could you be more specific? This is the wiki talking about HTTP/2 Server Push: en.wikipedia.org/wiki/HTTP/2_Server_Push – Saporific

Sorry, I didn't mean HTTP 2 server push, I meant streaming replies. There are other ways to do streaming replies, such as the venerable long polling, or websockets, for example. – Orientation

gRPC server does not send HTTP/2 "push and gRPC client ignores HTTP/2 "push". So gRPC's advantages inherited from HTTP/2 should not include "push". – Stallworth

HTTP/1.1 and HTTP/2 is out of topic here, gRPC use HTTP/2 just as a transport mechanism, all the application semantics in HTTP/2 are useless in gRPC. Many new protocols based on HTTP is just because it's firewall friendly, see SOAP, gRPC, websocket ... – Doorpost

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.

Doorpost

Answer 5

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.

Sibelius

Answer 6

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

Soothfast