2023 OWASP API Security Top 10 Best Practices
After four long years since the original…
Understanding JSON-RPC starts with JSON itself. JSON is a lightweight data-interchange format, meaning it exists in text form and does not need to be compiled to be interpreted. It is lightweight, which makes it suitable as a messaging format that can transfer data quickly. JSON messages are readable by humans, which is helpful for developers who work with it. JSON functions by breaking data, no matter how intricately mapped, into a manageable structure. This process makes it easy for multiple programming languages to process the data.
For these reasons, JSON is considered superior to Extensible Markup Language (XML). Indeed, since its launch in the early 2000s, JSON has essentially replaced XML as the messaging format for Application Programming Interfaces (APIs) and RPCs. It’s better at representing strings, numbers, values, and collections.
JSON-RPC uses the JSON message format to create procedure calls. Using JSON-RPC, an application can send a message to another app requesting that it perform a function, such as the processing of data. With JSON’s strong capabilities in data description, this usually works well. It’s an open, globally identified protocol.
A JSON-RPC request message can contain three possible elements: The method, which is a string that names the method to be invoked; params, which are objects or arrays of values that get passed along as parameters to the destination app; and id, a string or number that matches the response with the request that it is replying to.
The app that receives the JSON-RPC request proceeds to issue a response. The response includes a result, which is the data generated by the invoked method, and the request/response ID. It may also include an error if there is a problem with the receiving app.
JSON-RPC is known for its simplicity. Developers like to use it when they want to build an uncomplicated RPC relatively quickly. Given the reality that the more complex a piece of code gets, the more problems it will cause, simple is usually a good direction to take. It’s compact and lightweight, which is helpful in bandwidth or computing-constrained situations. JSON-RPC also defines network constraints that might affect data processing. It’s protocol-agnostic, so it can use transports like TCP/IP, HTTP, HTTPS, or even Unix domain sockets for its app-to-app interactions. Developers consider the built-in request/response matching ID field to be a benefit, as well.
Certain use cases favor JSON-RPC. Ironically, its “out of date” client/server architecture makes it advantageous in some situations. For one thing, JSON-RPC’s client/server setup has more flexibility for handling data than the architecture of RESTful APIs. If state is important, the server in the JSON-RPC setup can keep track of the state. JSON-RPC is also useful in cases when an immediate response is not required. For example, developers can set up a JSON-RPC to handle a queue of future actions. These factors contribute to JSON-RPC being a preferred RPC tool for blockchain and Web3 applications.
Developers and architectures tend to compare JSON-RPC with GraphQL and gRPC, though a better comparison might be with XML-RPC. However, given the current interest in GraphQL and gRPC, it’s worth taking a moment to contrast these two interoperability frameworks with JSON-RPC.
GraphQL is a query language and server-side runtime technology. Originally developed by Facebook a decade ago, GraphQL is used to fetch and transmit data to APIs. GraphQL is known for being easy to learn and easy to use. Developers consider it easy to integrate with a development environment—a big plus in some organizations. It’s comparable to JSON-RPC in this sense. Unlike JSON-RPC, GraphQL makes APIs faster and more flexible. Ultimately, GraphQL is not primarily a vehicle for RPCs.
gRPC is a remote procedure call framework, but it’s different from JSON-RPC on several levels. Known for being very fast and efficient with computing and network resources, gRPC uses a server-side API call to pass the procedure call’s parameters through a protocol buffer. The buffer turns the parameters into compact binaries that save space and bandwidth. It also speeds up the procedure call.
gRPC also uses an HTTP/2 connection to the server. There are several advantages to this approach, as well as limitations. HTTP/2 is great for fast exchanges of messages. It can also multiplex and stream messages, which is amazing for certain high-traffic and complex use cases. However, HTTP/2 is not available for regular web browsers—a major limitation.
JSON-RPC differs from REST, gRPC, and GraphQL. Each has its best fit. JSON-RPC remains a viable option for remote procedure calls for many use cases, especially those that favor simplicity and the advantages of the client/server model.
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.