JSON-RPC vs REST

JSON-RPC and REST represent action-oriented vs resource-oriented API design. JSON-RPC treats the API as a collection of callable functions. REST treats it as a collection of resources manipulated through standard HTTP methods.

JSON-RPC: Simple and Flexible

JSON-RPC is a lightweight RPC protocol. A request contains a method name and parameters. A response contains either a result or an error. That is the entire specification. It is transport-agnostic — the same JSON-RPC call can go over HTTP, WebSocket, TCP, or Unix pipes.

This simplicity makes it popular for internal services, blockchain APIs (Ethereum, Bitcoin), and protocol implementations like the Language Server Protocol (LSP) used by code editors.

REST: Semantic and Discoverable

REST leverages HTTP as an application protocol, not just a transport. Resources have URLs, operations use HTTP methods (GET, POST, PUT, DELETE), and responses use status codes. This enables HTTP caching, content negotiation, and discoverability through standard URL patterns.

When REST Feels Forced

Some operations do not map cleanly to resources and HTTP verbs. "Transfer money from account A to B" is awkward as a REST endpoint. "Calculate shipping cost for this order" is not clearly a resource operation. These action-oriented operations are more natural as RPC calls.

For more API design patterns, see our API concepts and system design interview guide. Explore pricing for practice.

The Bottom Line

Use REST for public, resource-oriented APIs where HTTP semantics, caching, and ecosystem tooling matter. Use JSON-RPC for internal, action-oriented APIs where simplicity and transport flexibility are priorities.