REST vs gRPC: when should I choose one over the other?

Question

I see more and more software organizations using gRPC in their service-oriented architectures, but people are also still using REST. In what use cases does it make sense to use gRPC, and when does it make sense to use REST for inter-service communication?

Interestingly, I've come across open source projects that use both REST and gRPC. For instance, Kubernetes and Docker Swarm all employ gRPC to some extent for cluster coordination, but also expose REST APIs for interfacing with master/leader nodes. Why not use gRPC up and down?

Answer 1

When done correctly, REST improves long-term evolvability and scalability at the cost of performance and added complexity. REST is ideal for services that must be developed and maintained independently, like the Web itself. Client and server can be loosely coupled and change without breaking each other.

RPC services can be simpler and perform better, at the cost of flexibility and independence. RPC services are ideal for circumstances where client and server are tightly coupled and follow the same development cycle.

However, most so-called REST services don't really follow REST at all, because REST became just a buzzword for any kind of HTTP API. In fact, most so-called REST APIs are so tightly coupled, they offer no advantage over an RPC design.

Given that, my somewhat cynical answers to your question are:

1. Some people are adopting gRPC for the same reason they adopted REST a few years ago: design-by-buzzword.

2. Many people are realizing the way they implement REST amounts to RPC anyway, so why not go with an standardized RPC framework and implement it correctly, instead of insisting on poor REST implementations?

3. REST is a solution for problems that appear in projects that span several organizations and have long-term goals. Maybe people are realizing they don't really need REST and looking for better options.

Answer 2

Depending on the gRPC's future roadmap, people will continue migrating to it and letting REST (over HTTP) "quiet".

gRPC is more convenient in many ways:

• Usually fast (like super-fast)
• (Almost) No "design dichotomy" ― what's the right end-point to use, what's the right HTTP verb to use, etc.
• Not dealing with the messy input/response serialization baloney as gRPC deals with the serialization ― more efficient data encoding and HTTP/2 which makes things go faster with multiplexed requests over a single connection and header compression
• Define/Declare your input/response and generate reliable clients for different languages (of course, the ones that are "supported", this is a HUGE advantage)
• Formalized set of errors ― this is debatable but so far they are more directly applicable to API use cases than the HTTP status codes

In any case, you will have to deal with all the gRPC troubles also since nothing in this world is infalible, but so far it "looks better" than REST ― and has actually proven that.

I think you can have the best of both worlds. In any case gRPC largely follows HTTP semantics (over HTTP/2) but explicitly allow for full-duplex streaming, diverging from typical REST conventions as it uses static paths for performance reasons during call dispatch as parsing call parameters from paths ― query parameters and payload body adds latency and complexity.