What is JSON-RPC? Protocol, Examples, REST Comparison

What is JSON-RPC?

JSON-RPC is a stateless, lightweight Remote Procedure Call (RPC) protocol that uses JSON for both request and response payloads. The current version is JSON-RPC 2.0, finalized in 2010. The protocol is transport-agnostic — it can run over HTTP, WebSocket, TCP, or even named pipes — and it's intentionally simpler than alternatives like SOAP or gRPC.

The protocol's biggest contemporary use is in blockchain ecosystems (Ethereum nodes communicate exclusively via JSON-RPC), but it's also common in internal microservices, IDE tooling (Language Server Protocol), and IoT.

JSON-RPC request structure

A JSON-RPC 2.0 request has four standard fields:

{
  "jsonrpc": "2.0",
  "method": "subtract",
  "params": [42, 23],
  "id": 1
}

• jsonrpc — protocol version, always "2.0".
• method — the function to call on the server.
• params — arguments (array for positional, object for named).
• id — client-generated unique ID; matched to response. Omit for notification (fire-and-forget) calls.

Response structure:

{
  "jsonrpc": "2.0",
  "result": 19,
  "id": 1
}

Or on error:

{
  "jsonrpc": "2.0",
  "error": {"code": -32601, "message": "Method not found"},
  "id": 1
}

JSON-RPC vs REST vs gRPC

Common JSON-RPC use cases

• Blockchain nodes. Ethereum, Bitcoin, and most blockchains expose JSON-RPC for client interactions (eth_getBalance, eth_sendTransaction, etc.).
• Internal microservices. Simple RPC between services without the complexity of gRPC.
• Language Server Protocol (LSP). Editor-to-language-server communication uses JSON-RPC.
• WebSocket APIs. Real-time apps that need bidirectional method calls.
• IoT devices. Lightweight enough for constrained devices.

Batch requests

JSON-RPC supports sending multiple requests in a single batch (array):

[
  {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": 1},
  {"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": 2}
]

Server responds with an array of results in the same order. Useful for reducing HTTP overhead on chatty APIs.

Standard error codes

Pros and cons

Pros

• Simple — easy to implement client and server.
• Transport-agnostic — works over HTTP, WebSocket, TCP, etc.
• JSON payloads — human-readable, broad language support.
• Batch support — multiple calls in one request.
• Lightweight — small dependency footprint.

Cons

• No standard schema language — informal "contract" between client and server.
• No native streaming (compared to gRPC).
• Batch responses can be confusing to debug.
• HTTP layer ignored (status codes always 200; errors in body).
• Less tooling than REST or gRPC.

FAQ: JSON-RPC

Is JSON-RPC still used?

Yes — heavily in blockchain (Ethereum, Bitcoin), Language Server Protocol, and internal microservices. Less common for public web APIs (REST dominates).

JSON-RPC vs REST: which is better?

REST for resource-CRUD APIs and public APIs. JSON-RPC for action-oriented APIs where "call this method" is the natural model. Neither is universally better.

Does JSON-RPC use HTTP status codes?

Often returns 200 even for errors (the error info is in the JSON body). Some implementations use proper HTTP codes; depends on the server.

How do I authenticate JSON-RPC?

Same as any HTTP API: bearer tokens in Authorization header, API keys, OAuth. Authentication is at the transport layer, not in the JSON-RPC payload.

What's the difference between JSON-RPC and JSON-RPC 2.0?

JSON-RPC 2.0 added explicit version field, improved error handling, and named parameters. Always use 2.0 for new development.

Can JSON-RPC do bidirectional communication?

Over WebSocket, yes — server can push notifications to client. Over HTTP, no (HTTP is request-response).

Test JSON-RPC APIs at scale with LoadFocus

If you're load testing JSON-RPC endpoints (especially blockchain nodes or internal RPC services), LoadFocus runs JMeter and k6 scripts that handle JSON payloads natively from 25+ regions with up to 12,500 VUs. Sign up for a free tier at loadfocus.com/signup.