Two acronyms trip up almost everyone who starts building on a blockchain: RPC and API. They sit side by side in docs, Discord threads, and half the tutorials online, often used as if they meant the same thing. Here’s the distinction in one line. An API is the general agreement that lets two programs talk. RPC is one specific way of writing that agreement — you call a function that happens to live on another machine. So RPC is a type of API, not a competitor to it. Get that straight and the rest of this topic stops feeling slippery.
Quick answer: An API is the overall agreement that lets two programs exchange data. RPC (Remote Procedure Call) is a style of API organized around calling remote functions, and JSON-RPC is the plain-text version that essentially every blockchain speaks. So when someone says “Web3 API” or “blockchain API,” there’s almost always a JSON-RPC API doing the work underneath.
The plan from here: we start with what an API and an RPC actually are, sit REST next to RPC, then take on gRPC — the version that throws a lot of backend developers. After that it’s on-chain, and why JSON-RPC ended up the default across Web3.
What an API Actually Is
Start with the wider term, since RPC lives inside it. An API — application programming interface — is a set of rules for how one program asks another for something. MDN describes it as an interface that hides complexity behind a stable set of operations. The restaurant metaphor is worn out, but it works: you order off a menu, the kitchen does the part you never see, a plate comes back. That same pattern runs most of the software you touch, from the weather widget on your phone to a blockchain endpoint handing back a wallet balance.
The main flavors of API
APIs don’t all share one design. They solve the same problem — structured communication between programs — but each makes different bets on speed, structure, and how long it takes to learn. Four come up often:
- REST — the web’s default. Everything is a resource (nouns like
/users), reached with plain HTTP verbs: GET, POST, PUT, DELETE. - SOAP — the strict elder. XML-based, verbose, still entrenched in banking and enterprise back-ends.
- GraphQL — you request exactly the fields you want in a single query, nothing spare.
- RPC-style APIs — organized around actions instead of resources. This is the branch that matters for Web3.
What RPC (Remote Procedure Call) Really Does
RPC stands for Remote Procedure Call, and the name is close to a full explanation. Your code calls a function — say getBalance(address) — that actually runs on a different machine, and the RPC layer hides the plumbing: packaging the request, shipping it across the network, unpacking whatever comes back. REST leans on nouns, the resources like /blocks. RPC leans on verbs: the action you want done. That verb-versus-noun split is what people are really circling when they pit RPC against REST.
That convenience hides a classic trap, though — maybe the oldest one in distributed systems. Making a remote call look like a local one papers over everything that makes networks unreliable. Martin Fowler, whose Patterns of Enterprise Application Architecture is a standard reference here, flagged it bluntly a long time ago:
“First Law of Distributed Object Design: Don’t distribute your objects!” — Martin Fowler
A local function doesn’t fail because someone tripped over a cable. A remote one can, and does — latency, timeouts, requests that die half-finished. In Web3 this is a daily fact of life, because every call travels the public internet to reach a node. Build with that in mind and your integrations survive the first slow node instead of toppling over.
JSON-RPC, the dialect Web3 speaks
The flavor of RPC you’ll actually meet in Web3 is JSON-RPC. It’s deliberately thin — each call is a plain JSON object carrying a method name, a few parameters, an id, and a version field. The JSON-RPC 2.0 spec dates to 2010, built on a 2009 draft, and it hasn’t needed much since. Every EVM chain speaks it, so it’s usually the very first thing a developer touches on a network.
json
{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": ["0xAbC...123", "latest"],
"id": 1
}Read that top to bottom and you can more or less guess what it does. You’re calling eth_getBalance with an address and a block tag; the node runs the method against the chain and returns a result tagged with the same id. No URL scheme to memorize, no guessing — just a named function and its arguments.
RPC vs API: The Difference in One Table
Here’s a clean way to hold it in your head. The API is the whole handshake. RPC and REST are two styles for writing it — one built around actions, the other around resources. Line them up and the contrast is hard to miss:
| Feature | REST API | RPC (JSON-RPC, gRPC) |
|---|---|---|
| Design model | Resource-based (nouns like /users) | Action-based (verbs like getUser) |
| Typical call | GET /users/1 | getUser(1) |
| Data format | JSON, XML, and others | JSON (text) or Protocol Buffers (binary) |
| Transport | HTTP | HTTP, WebSocket, or HTTP/2 |
| Caching | Built into HTTP | Handled manually |
| Best fit | Public web services | Internal services and blockchain calls |
Neither style is better in the abstract; they’re tuned for different jobs. REST shines when you’re exposing a tidy set of resources to the public web and want HTTP caching handed to you for free. RPC earns its keep when you just want to call a specific procedure with almost no overhead — which, as it happens, is exactly what talking to a blockchain feels like.
gRPC vs RPC: Google’s Faster Take on the Same Idea
So far RPC has been one thing. But the moment someone brings up gRPC, they’re really talking about a single, souped-up version of it. Google introduced gRPC as an open-source framework in February 2015, based on Stubby — the internal RPC system it had leaned on for more than a decade. Two decisions define it. Rather than ship text like JSON, gRPC serializes data with Protocol Buffers, a compact binary format, and moves it over HTTP/2. JSON-RPC optimizes for readability. gRPC optimizes for throughput.
What actually changes versus plain RPC
Every RPC makes a remote function feel local. gRPC just does it with more horsepower, through three technical choices that each trade a bit of simplicity for speed:
- Binary serialization — Protocol Buffers produce far smaller payloads than JSON, cutting both bandwidth and parse time.
- Strong typing — every service is pinned down in a
.protocontract, so message shapes are fixed and checked at compile time. - Streaming — HTTP/2 lets both sides push many messages over one connection, fully bidirectional.
The performance gap, in numbers
This is where the comparison stops being hand-wavy. A widely cited benchmark by engineer Ruwan Fernando clocked gRPC at roughly 7x faster receiving data and about 10x faster sending it against a JSON-over-HTTP setup, and a payload that runs a few hundred bytes as JSON can shrink to a fraction of that as a Protocol Buffers blob. Multiply that across millions of internal calls and the savings compound fast. That’s why gRPC became the default for service-to-service traffic at Google, and at plenty of large engineering orgs since. One catch, and it’s a big one: all of it assumes you own both ends of the connection.
| Feature | JSON-RPC | gRPC |
|---|---|---|
| Serialization | JSON (text) | Protocol Buffers (binary) |
| Transport | HTTP / WebSocket | HTTP/2 |
| Readability | Human-readable | Not human-readable |
| Setup | Minimal | Needs .proto files and code generation |
| Streaming | Via WebSockets | Native, bidirectional |
| Web3 tooling | Universal | Almost none |
| Best for | Blockchain and public APIs | Internal microservices |
How Web3 Actually Reaches a Blockchain
Back to Web3 — where, frankly, the RPC-vs-API decision has already been made for you. Anything you want to do on-chain — check a balance, read a contract, fire off a transaction — means talking to a node somewhere. Almost nobody runs that infrastructure themselves. They connect through a hosted endpoint: a blockchain API that accepts requests and returns chain data. On Ethereum and every EVM-compatible network, that endpoint is a JSON-RPC API, spelled out in the official Ethereum JSON-RPC docs. A Web3 API, then, is mostly managed access to that JSON-RPC layer, usually with richer data endpoints stacked on top.
This is also where infrastructure providers come in. Syncing a full node means hundreds of gigabytes and constant upkeep, so most teams rent access instead. A provider like NOWNodes, for one, hands you a JSON-RPC endpoint and an API key so you can call eth_getBalance against a live node without babysitting a server; its free START plan covers 100,000 requests a month, which is plenty to prototype against.
Reading the chain vs writing to it
Not every call to a blockchain API carries the same weight, and the divide maps neatly onto the methods. Reads — how many tokens sit in this wallet, what does this contract return — are cheap queries like eth_call and eth_getBalance, and they cost no gas. Writes are a different animal. A call like eth_sendRawTransaction actually changes on-chain state and does cost gas, because it broadcasts a signed transaction to the whole network. Your wallet checking a balance? That’s the read side. Swapping tokens on a DEX? That fires the write side.
Who actually relies on all this
Short version: nearly everything in the ecosystem. MetaMask and other wallets use a Web3 API to display balances and push transactions. Block explorers use it to render blocks and receipts. Trading bots and dashboards hammer it around the clock for live data. Even the on-chain AI agents that got popular lately reach the network through the same layer, renting access rather than running a chain. Which is the quiet reason your provider’s reliability ends up mattering as much as your own code — I’ve watched a laggy endpoint turn a perfectly good app into a stream of support tickets during a busy mint.
Why JSON-RPC Became Web3’s Default — and Where gRPC Still Fits
If gRPC is that much faster, why did Web3 stick with the older, slower JSON-RPC? Because speed is one variable among several, and for public blockchains it isn’t the deciding one. JSON-RPC is human-readable. It needs zero schema compilation — no .proto files, no special server. Anything that can fire an HTTP request can speak it. And most decisive of all, the entire Web3 toolchain grew up around it.
That last point does most of the work. Nothing else comes close on built-in support across the ecosystem. A single JSON-RPC endpoint drops straight into:
- Web3.js and Ethers.js — the two dominant JavaScript libraries
- Wallets — MetaMask, WalletConnect, and the rest
- Dev frameworks — Hardhat, Foundry, and friends
- Indexers, explorers, and dashboards — on basically every chain
Where gRPC still earns a place
None of this makes gRPC useless in Web3. It just works backstage rather than on the chain itself. No blockchain exposes a gRPC endpoint for node calls, but plenty of teams run gRPC between their own services: indexing pipelines, wallet back-ends, oracle networks, the internal machinery of some Layer-2 sequencers. The rule of thumb is short. Use a JSON-RPC API to talk to the chain, and reach for gRPC on the high-frequency traffic bouncing between your own servers. Which one you want usually comes down to the layer you happen to be standing on.
The Bottom Line
Strip it down and RPC vs API barely qualifies as a fight. The API is the contract; RPC is one popular way to write it. REST organizes that contract around resources, RPC around actions, and gRPC is a fast, binary take on RPC for systems you fully control. So: REST for public, resource-shaped services. JSON-RPC to talk to a blockchain. gRPC when you own both ends of a high-throughput internal link. In Web3 the question is effectively closed — a blockchain API almost always means a JSON-RPC API, because that’s the language every chain and every tool already shares. Once that clicks, the gRPC debate and the wider Web3 API picture stop being confusing and start being choices you make on purpose.
If your next move is actually connecting to a chain, you’ll want a reliable JSON-RPC endpoint before anything else works. NOWNodes gives you one with a free tier to start — fewer surprises when traffic spikes, and no node to babysit.
FAQ
Is JSON-RPC an API?
Yes. JSON-RPC is a specific kind of API — one that structures everything around remote method calls wrapped in JSON. “API” is the umbrella term; JSON-RPC is one standardized thing built beneath it. In Web3, a chain’s endpoint URL is almost always a JSON-RPC API, so the two were never opposites to begin with.
What’s the real difference in the RPC vs API debate?
Strictly speaking, it’s a slightly crossed comparison, because RPC is a style of API rather than a rival to one. The sharper question is RPC versus REST — the two main ways to design an API. RPC is action-based: you call procedures like getBalance. REST is resource-based: you hit nouns like /accounts. Blockchains went with the RPC style, which is why you reach them through methods instead of REST-style URLs.
Is gRPC faster than JSON-RPC?
For raw data transfer, usually — binary serialization plus HTTP/2 move payloads several times quicker. But on blockchain calls, serialization speed isn’t the bottleneck. Network latency and node processing eat most of the round trip, so gRPC’s edge barely shows for on-chain work even though it’s technically faster. For internal microservices, that edge is very real.
Why do blockchains use JSON-RPC instead of REST or gRPC?
JSON-RPC hits a sweet spot: lightweight, human-readable, transport-agnostic, and a clean match for method-style calls like eth_call. REST’s resource model fits procedure calls awkwardly, and gRPC would drag every wallet and library onto Protocol Buffers — something the ecosystem never signed up for. Ethereum standardized on a JSON-RPC API early, every EVM chain followed, and network effects locked it in as the default.
