In 2020, software engineer Ivan Velichko published an article titled “API Developers Never REST,” detailing the rise of alternate design strategies that have emerged since Roy Fielding published his dissertation in 2000. Yes, the title is a jokey hook designed to snag eyeballs and attention, but like all good humor, there’s a kernel of truth to it. Much has changed since Fielding first recommended creating a series of static assets that can be modified using a handful of verbs.

Numerous protocols have emerged since Fielding first published his dissertation. GraphQL, MQTT, gRPC, and JSON-RPC have all emerged as viable design principles in recent years, each with its own strengths, weaknesses, and passionate defenders. Today, we’re going to take a closer look at two approaches: JSON-RPC and REST. If you’re looking to better understand the technology powering Model Context Protocol (MCP), you’ve come to the right place!

What Is JSON-RPC?

JSON-RPC is a simple, lightweight remote procedure call (RPC) transmitted via JSON. It’s designed to be a simple way for one computer to tell another to “run this function using this data” and then return a result. Unlike REST, which relies on resources, like /usernames/addresses, for example, JSON-RPC transmits actions instead. JSON-RPC might transmit an action such as retrieve_user_address to achieve the same goal.

Examples of JSON-RPC

There are a number of remote procedure call APIs that adopt JSON-RPC. Microsoft’s Language Service Protocol is a good example of JSON-RPC in action, as well as a good illustration of one of the protocol’s strongest selling points. It allows code editors to interact with language servers, enabling autocomplete, built-in definitions, and syntax checking. Using JSON-RPC enables code editors to consult the language server regardless of what transport protocol you’re using. WebSockets, local pipes, or streaming environments can all use JSON-RPC with no trouble.

MCP is probably the most famous example of JSON-RPC in action, though. Anthropic’s agentic protocol uses JSON-RPC to safely invoke tools like web search or database integration. Best of all, it lets agents process batch requests, letting you integrate agentic functions like summarizing a text into your development environment.

What Is REST?

Comparing Representational State Transfer (REST) to JSON-RPC isn’t entirely fair, as it’s impossible to make an apples-to-apples comparison. As we have seen, JSON-RPC is a protocol. REST, on the other hand, is a philosophy for an architectural style. Instead of being a specification that requires a particular file format, like JSON-RPC or GraphQL, REST is more like a checklist for developers to follow. The six constraints that define REST are:

1. Uniform Interface
2. Stateless
3. Cacheable
4. Client-Server
5. Layered System
6. Code on Demand (Optional)

Examples of REST

The World Wide Web is the best and easiest example of REST. A webpage is an example of a static resource. Just as importantly, the request from the web browser doesn’t return the site itself but the HTML, which is then decoded by the browser. This is an example of a uniform interface in action. A local machine can also save copies of code locally, improving performance. This is an example of how the World Wide Web is both stateless and cacheable.

For a more modern example of REST in action, consider the Stripe API. Often cited as the gold standard for REST architecture, every resource, including actions, gets its own static resource. Instead of transmitting a function as you would in JSON-RPC, you’d send a GET or POST HTTP request to the /v1/charges endpoint. Developers never have to guess how to use a resource when it’s RESTful, as all resources and HTTP verbs are uniform.

Understanding the Differences Between JSON-RPC and REST

As we’ve said, making a 1:1 comparison between JSON-RPC and REST isn’t entirely possible. First of all, JSON-RPC is a protocol. REST, on the other hand, is a design philosophy. Furthermore, JSON-RPC is organized around actions while REST centers on resources. JSON-RPC is transport-agnostic, while REST is typically implemented over HTTP.

JSON-RPC is also able to be far more efficient, as it can bundle numerous separate commands into a single request. REST often suffers from over-fetching or under-fetching, on the other hand, as it has to serve an entire resource. If a /users endpoint contains 50 names but you only need one, all 50 records will have to be transmitted and then filtered on the user’s end. REST compensates for this limitation with excellent cacheability, however, as it uses HTTP, the same protocol that powers the web. RPC protocols like JSON-RPC often require custom implementation as they’re not standardized and aren’t necessarily transmitted with HTTP.

Last but not least, JSON-RPC uses direct mapping, making it incredibly easy to extend. If you need a new function, you just have to write one. The downside of this is lack of discoverability and difficulty of use. Without checking the documentation, users have no way of knowing what functions exist, let alone how to use them. This makes REST far easier and more intuitive for users, as each endpoint only accepts a handful of standardized HTTP verbs.

When To Use JSON-RPC vs. REST

There’s a reason that REST has been the guiding principle and gold standard of API design since Fielding endorsed the approach in 2000. It’s no coincidence that REST is still the most popular API architecture, by a wide margin. 92% of APIs still use REST as of 2025. That being said, it’s not going to be the best approach for every task. Some situations will call for REST. Others would be better suited for a different API architecture, like JSON-RPC.

When you’re deciding between JSON-RPC vs. REST, breaking things down into the actions versus resources dichotomy will help simplify your decision. If you were launching a simple commercial API for a pet store, writing a get_pet_name function might not be necessary when a simple GET /pets/<petname> endpoint will suffice. If you’re not planning on modifying an endpoint excessively, REST will likely meet your needs. It’s also likely a better fit if your API is intended for public use, as it uses a uniform structure and commands. This way, users won’t have to consult the API documentation to know how to use your API.

If your API will be performing complex calculations or transactions, however, JSON-RPC may be a better fit. If a pet store wanted to apply a discount to all of the pets in the store as a promotion, modifying every single <petname> could quickly become a nightmare. A simple apply_pet_discount function would be a far easier, more efficient, and accurate way to implement the changes.

The Future of JSON-RPC vs. REST

The fact that one’s a specification and the other’s a design philosophy isn’t the only reason there’s no debate between JSON-RPC vs. REST. The future of JSON-RPC vs. REST is going to include both. As we have seen, even RESTful tools and resources might use JSON-RPC by transmitting a function to a RESTful resource, for example. You might not feel like writing a new function for every GET, PUT, or DELETE verb, for another. The existence of both JSON-RPC and REST just means you’ll need to think more carefully when implementing a project instead of simply adopting a standardized solution.