Json-RPC vs REST vs GraphQL

I'll try to explain briefly and practically why, in many real projects, Json-RPC is a stronger foundation for an API than REST or GraphQL.

Introduction

REST and GraphQL have long been popular standards. But as systems grow more complex, it often turns out that the core of an API does not boil down to simple CRUD over resources.

When business logic becomes complex, teams need an approach that:

• describes calls predictably;
• does not overload the network;
• scales easily;
• does not force them to invent non-standard "workaround" solutions.

This is where Json-RPC often offers a better balance.

Where REST and GraphQL lose efficiency

REST

REST integrates well with HTTP and is convenient for resource-oriented scenarios. But in complex systems it often leads to:

• a large number of requests for a single business operation;
• blurry API contracts when you need commands rather than CRUD actions;
• a "zoo" of implementations (different verbs, query/body/header patterns, non-standard approaches across teams).

As a result, the API becomes harder to maintain and scales worse.

GraphQL

GraphQL solves some of REST's problems: the client can get exactly the fields it needs. But other challenges appear:

• higher backend complexity;
• more complex queries and harder load control;
• additional rules for security, caching and rate limiting.

So GraphQL is a powerful tool, but not always the cheapest to operate.

Why Json-RPC is often more practical

Json-RPC separates transport from business logic. The API is described not in terms of "resources" but as clear procedures (method + params) that map directly to business actions.

This is especially useful where the API is not about "managing entities" but a set of commands and scenarios.

Key advantages of Json-RPC

1. A standardized request and response format

Every call has a predictable structure:

• method: the procedure name;
• params: the input parameters;
• result or error: the standard response.

Less improvisation in the team, simpler contracts, easier testing.

2. A natural model for business operations

If the system has many actions like calculatePrice, approveOrder, startWorkflow, Json-RPC lets you describe them directly, without artificially forcing them into a CRUD model.

3. Batch requests

Json-RPC supports batch calls, so several operations can be executed in one request. This:

• reduces the number of round trips;
• cuts network costs;
• speeds up the integration of complex scenarios.

4. Transport independence

Json-RPC is not tied to a single transport: HTTP, WebSocket, TCP and other options can be used depending on the task.

This gives flexibility when the architecture changes, without completely rewriting the API contract.

5. Better scalability of business logic

Individual procedures are easy to extend and version. New business functions are added as new methods rather than by complicating "resource" schemas.

When to choose what

• REST: simple resource APIs dominated by CRUD.
• GraphQL: many complex read scenarios where control over response fields is critical.
• Json-RPC: APIs with a large share of command-style business logic, where predictability, batch calls and transport flexibility matter.

Conclusion

Json-RPC is an underrated but very strong approach for modern APIs. It lets you build contracts closer to business actions, reduces technical noise and simplifies the evolution of the system in the long run.

For projects where the API is not just CRUD but primarily business commands, Json-RPC is often the most practical choice.