How is GRPC different from REST?

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

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