Json-RPC vs REST & GraphQL

Last modified by Ashterix on 2024/05/20 12:55

rpc_vs_rest_vs_grafql

My View on Modern APIs

I will try to express my opinion here and explain why Json-RPC is a better choice for building APIs.

Modern data transmission technologies dictate the pace of development in many industries and business methods. As companies demand greater speed, adaptability, and efficiency from their systems, the need for advanced API development methods also grows. One such method, which stands out for its efficiency and flexibility, is Json-RPC, a method often underestimated compared to more popular REST and GraphQL.

Analysis of REST and GraphQL

REST, which has dominated web development over the past decades, became popular due to its convenience in integrating with HTTP, but it is often used out of inertia, simply because developers are accustomed to it and do not notice the "hacks" they must make from project to project to meet business logic requirements. Inevitably, as the complexity of applications and their requirements grow, REST begins to show its inadequacy, as this approach can require numerous requests to the server to perform simple operations and scales poorly for complex systems.

GraphQL solves some of these problems by allowing clients to define what data they need in a single request. However, this method also introduces its own challenges: complexity of backend implementation, increased server load due to the complexity of queries, and potential inefficiency in resource use.

The main problem with these two approaches is that both REST and GraphQL are resource-oriented standards. Their primary task is to transfer elementary database work to the client level, that is, providing CRUD at the level of HTTP requests (although the concept of "resource" may involve some abstraction). In real systems, such requests are no more than a third of the entire backend API, and for other needs, developers have to reinvent the wheel.

Trying to make the entire API maximally RESTful significantly increases the amount of code and burdens the network, because the rest of the two-thirds of requests—in the form of backend commands—boils down to actions that are weakly related to CRUD over resources. There are too many ways to send such requests and they are not regulated: GET, POST, PUT, PATCH, HTTP headers, cookies, body, form data, GET query parameters, json, content-type, HTTP codes...

When there are several developers in a team, and each has their own view of the world, it quickly turns into a mess. Even a single developer often finds themselves at a dead end, not understanding how to further live with all this mishmash of parameters, verbs, and nouns of a RESTlike API.

All genius is simple!

The search for solutions to these problems led to the creation of the simple, understandable, and in my opinion absolutely underrated Json-RPC specification. This specification completely separates the business logic of the client-server request from HTTP with its rich but unnecessary inner world.

Advantages of Json-RPC

Json-RPC is a bright example of the evolution of architectural approaches in the development of web applications and system interfaces. This protocol allows remote procedure calls on the server by sending commands in the form of Json objects. As a transport, any available technology can be chosen, such as HTTP POST requests. This universality and simplicity provide a high level of integration and interaction between components of distributed systems.

Standardization of Requests and Responses

In Json-RPC, all requests and responses are standardized, which greatly simplifies the development and maintenance of APIs. Each request contains two main components:

  • Method: The name of the method or procedure to be called on the server. This is analogous to an endpoint in REST but provides greater flexibility since it is not limited to standard HTTP methods.
  • Params: Parameters that are passed along with the request. They can be presented as an array or object depending on the specific method.

Server responses are also structured and predictable, including:

  • Result: The result of the procedure if it was successful.
  • Error: Information about the error if problems occurred during the procedure execution.

Differences from REST

Unlike REST, which is resource-oriented and based on CRUD operations, Json-RPC is not limited to four basic operations and allows defining almost an unlimited number of procedures. This makes Json-RPC an ideal alternative for scenarios where complex and specific operations are needed, which are difficult to model through standard HTTP requests.

Using Json for Data Exchange

The name "Json-RPC" comes from the data exchange format (Json), which is lightweight, easy for humans to read, and simultaneously machine-readable. This allows systems to easily exchange data across networks, regardless of the programming language used to implement client and server components. Json provides high flexibility and data processing speed, which is critically important for the development of modern web applications and mobile apps.

Batch Requests

Json-RPC minimizes the number of requests to the server since it allows the execution of multiple actions within a single request. This not only reduces network load but also eases integration for developers, freeing them from the need to navigate the complexities of many HTTP methods.

Transport Independence of Json-RPC

One of the key advantages of Json-RPC is its transport independence. Unlike many other protocols that are closely linked to specific transport mechanisms, Json-RPC can function on various transport protocols. This means that it can be easily integrated with different systems and adapted to various network conditions without losing functionality or efficiency.

Flexibility in Choosing Transport Protocols

Json-RPC can be used through HTTP, WebSockets, TCP, UDP, and other transport protocols, making it an extremely flexible option for developers. This transport independence allows using Json-RPC in various usage scenarios, including high-performance distributed systems, real-time web applications, and in embedded systems and IoT projects.

Benefits of Transport Independence:

  • Compatibility with different environments: Json-RPC does not require protocol-specific implementations, ensuring its easy implementation in existing systems without the need for reconstruction or significant changes.
  • Scalability: The ability to work with various transport protocols allows Json-RPC to scale according to project needs, including the possibility of optimizing for high performance or ensuring greater reliability.
  • Efficiency: Using the optimal transport protocol for specific conditions can reduce latency, optimize data transmission speed, and reduce network load.

Practical Application

Implementing Json-RPC in complex systems that require fast processing of large volumes of data or real-time user interaction can significantly improve their efficiency. For example, using WebSockets for continuous data exchange between the client and server in real-time.

Impact on Business Logic Development

Json-RPC opens new possibilities for creating modular and flexible systems. Developers can define specific business operations as separate procedures, allowing dynamic changes and expansion of functionality without rewriting existing code. This approach significantly speeds up the development of new features and allows for more flexible responses to dynamic market requirements.

Conclusion

Considering the advantages outlined above, Json-RPC is an ideal candidate for selection as the main API architecture in a wide range of projects. This technology not only improves the interaction between different parts of IT infrastructure but also facilitates rapid adaptation to new business demands and technological conditions.

Choosing Json-RPC can significantly optimize development and implementation processes, providing the resilience and flexibility that are key to modern business ecosystems.