101

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

enter image description here

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

Naman
  • 23,555
  • 22
  • 173
  • 290
Jwan622
  • 8,910
  • 11
  • 56
  • 125
  • 20
    «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'. – weirdan Apr 28 '17 at 14:24

4 Answers4

112

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      |
+-----------+----------------+
| 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

Acumenus
  • 41,481
  • 14
  • 116
  • 107
mmccabe
  • 1,989
  • 1
  • 19
  • 24
  • 3
    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? – Jwan622 Apr 30 '17 at 03:56
  • 3
    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. – mmccabe May 01 '17 at 04:31
  • Here is a nice intro to gRPC: https://medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b Here is a demo of gRPC: https://github.com/mmcc007/go – mmccabe May 01 '17 at 04:41
  • @mmccabe 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? – Lakshman Diwaakar Jul 03 '17 at 02:05
  • LakshmanDiwaakar: I see you asked the question over [here](https://stackoverflow.com/q/44877606). – Martin Andersson Sep 07 '17 at 16:10
  • 1
    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 ;) – Martin Andersson Sep 07 '17 at 16:10
  • 4
    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! – Martin Andersson Sep 07 '17 at 16:12
  • @MartinAndersson What is that solution, especially for big data calls, possibly streaming? – Acumenus Jun 19 '18 at 23:47
  • @mmccabe 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. – kabirbaidhya Apr 08 '19 at 15:36
  • @kabirbaidhya 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. – mmccabe Apr 08 '19 at 21:44
45

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

Increasingly Idiotic
  • 4,255
  • 2
  • 22
  • 57
user2077221
  • 767
  • 7
  • 7
4

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

Denis Wang
  • 798
  • 8
  • 12
  • 1
    Server push doesn't need HTTP/2. – Robin Green Oct 04 '17 at 12:56
  • Could you be more specific? This is the wiki talking about HTTP/2 Server Push: https://en.wikipedia.org/wiki/HTTP/2_Server_Push – Denis Wang Oct 05 '17 at 13:14
  • 2
    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. – Robin Green Oct 05 '17 at 14:43
  • 1
    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". – user675693 Mar 13 '19 at 21:48
  • 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 ... – tangxinfa Sep 18 '20 at 09:38
0

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.

tangxinfa
  • 1,142
  • 10
  • 12