When should I use REST versus gRPC for my APIs?

Use REST with JSON for external-facing APIs where developer convenience, human readability, and broad tooling support matter most. Use gRPC for internal service-to-service communication where performance is critical and services run in close proximity within the same infrastructure, as the binary Protocol Buffer format significantly reduces processing overhead.

What problem does service mesh solve that API gateways don't?

Service mesh provides security, observability, and traffic control for internal service-to-service communication without forcing all traffic to hairpin through a central gateway. This avoids the cost of paying per-call for internal APIs (which typically outnumber external calls by two orders of magnitude) and eliminates the single point of failure that a central gateway represents.

REST, gRPC & Service Mesh: Evolution of Service APIs

Name: REST, gRPC & Service Mesh: Evolution of Service APIs
Uploaded: 2026-05-26T19:56:52-04:00
Duration: 22 min 29 s
Description: How did we go from manual 15-disk Windows installs to the seamless automation of modern cloud native environments? In this inaugural episode of I.O.U. An Explanation, host Dan Ciruli sits down with industry legend Louis Ryan (CTO of Solo.io, co-founder...

Nutanix

05/26/2026

0 (0%)

Report Like Favorite

TL;DR

RESTful APIs with JSON democratized service communication by building on widely-adopted HTTP and browser standards, making APIs human-readable and eliminating the need for proprietary tooling that characterized earlier protocols like CORBA.
gRPC was created to address REST's performance overhead for internal service communication, using binary Protocol Buffers instead of ASCII JSON to keep data in computer-native format—critical when services are microseconds apart rather than milliseconds.
Service mesh provides governance, security, and observability for internal APIs without code changes, with ambient mesh architecture reducing operational overhead by moving proxies into infrastructure rather than deploying sidecars alongside every application.
Asynchronous communication will not replace synchronous patterns as the dominant model due to complexity—most software is intrinsically synchronous, and async benefits are already captured through databases and event queues at specific layers.
Open sourcing technologies like gRPC and Istio proved essential for adoption, allowing the industry to standardize on shared infrastructure rather than fragmenting around proprietary solutions from individual vendors.

The REST Revolution and API Democratization

The conversation traces the evolution from proprietary communication protocols like CORBA to the REST revolution that democratized API development. Louis Ryan explains how the alignment of JSON (already widely used in browsers) with HTTP standards created unprecedented momentum for RESTful services. This combination made APIs human-readable, eliminated the need for specialized tooling, and enabled the Web 2.0 explosion of commerce and integration. The standardization through OpenAPI specifications allowed developers to easily document and consume APIs, while intermediary tools for debugging, security analysis, and documentation generation flourished around these open standards.

gRPC: Performance for Internal Service Communication

Ryan details the creation of gRPC at Google to address performance limitations of REST for internal service-to-service communication. When services run in the same data center, the overhead of translating data to ASCII JSON and back becomes material—what Ryan describes as analogous to printing a floppy disk's contents, mailing the paper, and scanning it back in versus just shipping the disk. gRPC uses Protocol Buffers (Protobuf) for binary representation, keeping data in computer-native format throughout transmission. Built on HTTP/2 standards and released as open source, gRPC has become the de facto standard for high-performance internal APIs where proximity makes efficiency critical.

Service Mesh: Governance Without Code Changes

The discussion covers how service mesh technology addresses the challenge of governing internal API communication at scale. Ryan explains that while external APIs flow through API gateways for security and rate limiting, internal microservices need similar controls without the cost and failure risk of hairpinning all traffic through a central gateway. Istio's initial sidecar proxy model provided comprehensive features but created maintenance burdens—upgrading meant rolling updates across entire application fleets. The evolution to ambient mesh pushes lightweight proxies into the infrastructure layer while keeping heavyweight features in the network, dramatically reducing operational overhead while maintaining transparent control over service communication without requiring application code changes.

Chapters

0:00 - Introduction to I.O.U. An Explanation
1:08 - The Before Times: Floppy Disk Era
4:14 - The REST Revolution
9:38 - Why REST Isn't Enough
11:24 - Protobuf vs ASCII Efficiency
13:18 - Open Source for Technology Success
15:42 - Introduction to Service Mesh
18:20 - Sidecar Proxy Challenges
18:59 - Ambient Mesh Architecture
22:47 - Hot Take: Async vs Sync

Key Quotes

4:53 "There was a democratization, I would say, right? There was an alignment around JSON, which was already widely used in the browser space for all the tooling on the backend side. And so the tooling became more ubiquitous, more consistent, also easier to read for humans."
10:20 "When the consumers of your APIs are running on the same physical infrastructure in the same data center as the API that they're calling, then the costs and the overheads that REST adds to an API call start to become much more meaningful, right? If I'm 80 milliseconds away, processing a REST call is not that much of a relative overhead to the API call. When I'm 50 microseconds away, now it's a really big deal."
12:01 "It's not like, you know, I take my floppy disk, I print out the document that's on it, and then I send you the document and you scan it back in and put it into a, right? Instead, you want to ship the floppy disk. It goes over the wire."
13:36 "Generally, if you want a technology to be successful, not a product, a technology, you should probably open source it, right? Because that's how you're going to foster adoption. That's how you're going to get people comfortable with it, right? And that's how you're also going to get them to help you make it better."
18:22 "Maintenance became a big problem with sidecars, because if I have to upgrade the technology we use to do it, that means I have to run a rolling update of every application in my fleet. And that's painful, to put it mildly."
20:58 "Cold take. Just complexity, right? How you have to think about building your software. If you don't start thinking asynchronously, it's really hard to start rewriting your system to become async when it was sync. The overwhelming majority of software today is intrinsically sync."

Categories:

Tags:

Show more Show less

TL;DR

The REST Revolution and API Democratization

gRPC: Performance for Internal Service Communication

Service Mesh: Governance Without Code Changes

Chapters

Key Quotes

Adopting AI: From Illusion to Intentional Control

Harnessing AI for Smaller Teams: Strategies for Secure Implementation

Spring of Satori: Delving into Recent Findings and 2026's Threat Landscape

Deciding Between Purchasing and Developing Solutions

Deciding Between Building or Buying Data Classification: Understanding DIY Costs