A detailed comparison of REST and gRPC

While this is a nice overview (I wouldn&#x27;t call it detailed), I feel it misses the points of REST, gRPC, and GraphQL. I think it&#x27;s a more useful engineering decision to first filter based on how you want an API to be used, and then to filter based on the implementation details such as these.<p>The whole point of REST is that it&#x27;s discoverable. Now web standards didn&#x27;t quite manage to standardise HATEOAS, so sadly full machine discovery is unlikely via an API, but you can build quite adaptable clients that can respond to changing APIs well, going as far as optimising client usage by changing API responses without redeploying clients. That may or may not be something you want in an API, but it&#x27;s worth considering, because it&#x27;s not going to happen with gRPC.<p>GraphQL, like REST, is about the objects and relationships, and lends itself well to building highly capable client-side caching layers when you introduce the Relay patterns to it – particularly globally unique IDs. Given GraphQL&#x27;s well defined schema it&#x27;s relatively easy to build generic caching mechanisms. Again, this may or may not be something you want in an API.<p>gRPC doesn&#x27;t really allow for any of this, if you want it you&#x27;ve got to invent it all yourself. But that might be ok! Server to server calls rarely need a big cache to work around poor networking. gRPC does however offer considerably more control over streaming behaviour, more standardised error handling than GraphQL, and more.<p>There are quite a few factual errors in this post, like REST not being schema based (that&#x27;s up to the implementer), no streaming in REST (not necessarily true).<p>When deciding on an API technology the first questions must be &quot;who is the consumer&quot;, and &quot;what are their constraints&quot;. These will often lead to just one or two of the options here, then you can drill down into the details like tooling, API design, and so on.

gRPC is so much cleaner and easier to work with for the APIs.<p>- Error codes are well defined (vs &quot;should I return 200 OK and error message as a JSON or return 40x HTTP code?&quot;)<p>- no semantics ambiguity (&quot;should I use POST for query with parameters that don&#x27;t fit URL query param, or POST is only for modifying?&quot;)<p>- API upgrades compatibility out of the box (protobuf fields identified by numbers, not names)<p>Not to mention cross-platform support and autogenerating code.<p>I use it in multiple Flutter+Go apps, with gRPC Web transparently baked in, and it just works.<p>Once I had to implement chunked file upload in the app and, used to multiform upload madness, was scared even to start. But without all that legacy HTTP crap, implementing upload took like 10 mins. It was so easy and clean, I almost didn&#x27;t believe that such a dreadful thing as &quot;file upload&quot; could be so easy. (years of fighting HTTP legacy).<p>Compared to the &quot;traditional&quot; workflow with REST&#x2F;JSON the downside for me is, of course, the fact that now you can&#x27;t help but care about API. With web frameworks the serialization&#x2F;deserealization into app objects happens automagically, so you throw JSON objects left and right, which is nice until you realize how much CPU&#x2F;Memory is being wasted for no reason.<p>Also, check out drop-in replacements for cases where you don&#x27;t need full functionality of gRPC:<p>- Twirp (Twitch light version of gRPC, with optional JSON encoding, HTTP1 support and without streaming) - <a href="https:&#x2F;&#x2F;github.com&#x2F;twitchtv&#x2F;twirp">https:&#x2F;&#x2F;github.com&#x2F;twitchtv&#x2F;twirp</a><p>- Connect - &quot;Better gRPC&quot; <a href="https:&#x2F;&#x2F;connect.build&#x2F;docs&#x2F;introduction&#x2F;" rel="nofollow">https:&#x2F;&#x2F;connect.build&#x2F;docs&#x2F;introduction&#x2F;</a>

Why nobody ever mentions JSONRPC 2.0 over WebSockets? It&#x27;s one page doc simple, debuggable, supports realtime notifications, is bidirectional, works on browser and your internal apis in pretty much any language and probably fits 99.9% of projects for their requirements. JSON encoding&#x2F;decoding is extremely fast in any language due to its pervasive usage.

gRPC is a pain in the ass to setup. I strongly disliked the web client library for it.<p>I don&#x27;t like REST because it&#x27;s basically become a specific url structure with semantic http methods (e.g. POST for create). Practically nobody bothers with the HATEOS stuff. Things start breaking down if you have a complex resource hierarchy and custom methods.<p>I&#x27;ve personally just settled on rpc using json. Any consumer of the api REST or otherwise is going to check the docs for the correct endpoint, at which point there&#x27;s little to no difference between rpc and rest.

REST is an architectural <i>style</i>, HTTP is a protocol that implements that style. People really should read the Fielding thesis to understand what it is, and what it <i>isn&#x27;t</i>.<p>The concept of resources maps well to URLs, which <i>name</i> things, ie a URL is a <i>noun</i> not a verb. The REST style is about two endpoints <i>transferring</i> their current state of a resource, using a chosen <i>representation</i>, whether JSON, XML, JPG, HTML etc.<p>gRPC is a remote procedure protocol that uses protobufs as a TLV binary encoding for serializing marshalled arguments and responses. It requires clients and servers to have compiled stubs created to implement the two endpoints. Like most RPC, it is <i>brittle</i> and its abstraction as a procedure call <i>leaks</i> when networks fail.<p>GraphQL is a <i>query</i> protocol for retrieving things, often with associated (ie foreign key) relations. The primary use is defined in the &quot;QL&quot; of the name.<p>The benefit of HTTP and the use of limited verbs and expressive nouns (via URLs) is that HTTP defines the operation, expected idempotency, and expected resource &quot;state&quot; after an HTTP request&#x2F;response has occurred. It has explicit constructs for caching, allowing middleware to optimize responses.<p>There&#x27;s nothing in HTTP that requires JSON, the choice of media type is negotiable between the client and server. The same server URL can serve JSON, XML, protobufs, or any other format.<p>gRPC is yet another attempt to extend the function call of imperative languages to the network. It is the latest in a long line of attempts, Java had RMI, there was SOAP and XML-RPC. Before that there was CORBA and before that there was ONC-RPC. They all suffer from the lack of discoverability, the tight binding to language implementations, and the limitations of the imperative languages that they are written in.<p>They all end up failing because of the brittle relationship between client and server, the underlying encoding (XDR, IDL, Java etc etc) of the marshalling of arguments and responses is essentially irrelevant.

I don&#x27;t know why JSON over HTTP gets so little love on here. It&#x27;s probably the most popular option. If you don&#x27;t want a resource-oriented API you don&#x27;t need to throw the baby out with the bathwater and go all the way to gRPC.

When I converted all the micro services in my big app from HTTP to WebSockets my test automation performance in the browser instantly became 7x faster. I am still using JSON and not using protobuf.<p>The reason for the performance difference is that a WebSocket is a single statefull TCP socket with a tiny extra binary frame header sending messages back and forth. HTTP is stateless so it creates a new socket for each and every message. HTTP also has a round trip, request&#x2F;response. The round trip means twice the message frequency as compared to the fire and forget nature of WebSockets.

gRPC is kind of plagued by its strong coupling with Protobuf, who is a disappointment.<p>Imo, what could have been a decent piece of engineering has been killed by that &quot;you should do like Google does&quot; mentality, with some highly debatable design choices leaking in an unrelated standard (hello defaults).

I don&#x27;t understand why GRPC would use HTTP2 as a default instead of WebSockets. HTTP was designed for transferring documents and resources in a way which maintains file types. When you&#x27;re just transferring raw data, HTTP adds unnecessary overhead and complexity. WebSockets, on the other hand, was designed precisely for raw data transfers.

Fwiw, you can&#x27;t use gRPC over HTTPS proxies if they don&#x27;t implement ALPN correctly, and some of the biggest vendors of corporate security HTTPS proxies don&#x27;t. It turns out a bunch of Google Cloud APIs are only available as gRPC. So you basically can&#x27;t use Google Cloud APIs from a corporate network.<p>The internet and common protocols used to be designed with real world use cases in mind, but now all technology is designed with only one generic consumer user in mind, and everybody else gets left behind.