JSON-RPC 1.0 Specification Interpretation

JSON is probably the simplest form of text data on the planet, readable, flexible, small in volume, easy to encode and decode, fast, and good for Unicode and special character support. In contrast to the XML, you know how many bytes are wasted by the additional various label nodes. JSON characters are used by default in Unicode, and all non-acsii characters can be represented in \uxxxx without the need for additional escaping. In contrast, XML needs to use escape or CDATA (like the pre tag in HTML), or Base64 to represent special data. Of course, the shortcomings are also obvious, than the data of binary data structure is large, codec slow, there is no complete type system, limited ability to express.

JSON-RPC is a remote procedure call (CALL,RPC) technology that uses a JSON object as a data carrier.

" Does distributed computing has to be Any harder than this? I don ' t think so '--Jan-klaas Kollhof

JSON-RPC's design goal is two words: 简单 . We know that an RPC framework is for interactive communication between 2 systems, which requires the definition of an intermediate data transfer format. In order to transform the platform data structure with the system itself, it is necessary to provide a set of functions for serializing and deserializing this data format. Then there is the need for some kind of communication protocol to transmit the actual remote call data. Finally, it is necessary to implement the Code piles (Stub&skeleton) on both ends of the communication, which is usually a proxy based on dynamic agent or AOP implementation, an interface structure that can be called, so that the framework hides all other technical details (data format, serialization, network transmission, etc.). The program can invoke the remote method just like the local method call. To summarize:

1. Data format
2. Serialization features
3. Communication protocols
4. Code piles

The JSON-RPC specification only explicitly specifies the data format (that is, JSON), the Communication Protocol (TCP or HTTP) is recommended, and serialization and code piles are not mentioned. Of course, serialization is better, and there are rich JSON serialization libraries in various languages (see reference 1). Then the code pile is completely left to the framework to implement the JSON-RPC specification itself to deal with, the communication protocol this piece of the specific processing also need to consider the framework itself.

We know that the communication between the two systems may be synchronous blocking (each request waits for the next request after the response is completed), or it can be asynchronous, non-blocking (Request 1 is finished, continue to send request 2, which response comes back to deal with which response), or it may be one-way (one-way, no matter, Do not respond to information), or may be request-response (Request-response), each request requires an explicit reply.

json-rpc1.0, the two sides of the communication as the equivalent of two side.

• Defines how to send requests and return results, error messages,
• How to handle a one-way and request-response interaction process,
• And how bidirectional asynchronous requests match results and requests,
• Finally, a simple type hint (class hinting) extension is added (the idea is good, but the two sentences have no details and are very chicken).

Let's take a look at the specifics of the specification.

Requests (Request)

The requester sends a JSON object that represents the method that it wants to invoke, as shown in the following example:

{ "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}

It contains three key elements:

• Method: Means to invoke
• Params: An array that represents a parameter
• ID: Indicates that the request needs to be responded to, and the service party needs to provide a response with the same ID of 1.

This ID field is very interesting, the general synchronous RPC does not need to consider this thing, because in general, an RPC request contains only one request, and the request will wait for the response information to return, before this will always block the caller's processing thread, so that the entire RPC is like the local method called.

Response (response)

A typical response message is as follows:

{ "result": "Hello JSON-RPC", "error": null, "id": 1}

The key elements are also 3:

• Result: Indicates the return result, if the error result must be null
• Error: Indicates an error and the error must be NULL if the request succeeds
• ID: Indicates the request ID corresponding to this response

Notice (notification)

The notification information is similar to a request, but the ID must be null. The notification represents a one-way request, cannot reply, can be sent by the request imagining to the service party, can also be sent by the service imagining to the requester (the agreement in principle requires the two sides, can be the requester or the service party, this point on HTTP is not satisfied).

Communication (transport)

• Tcp

The Protocol recommends that both parties interact with a byte stream under TCP. At this time the two sides are equal. You must send an error message to all unanswered requestors before closing the connection. An invalid request or response will cause the connection to close.

• HTTP

Under some restrictive conditions, HTTP can also be used as a communication protocol. At this time the communication between the two sides obviously not peer, with the client and server side.

Given the overhead of HTTP, the protocol allows one post to carry multiple RPC requests or notifications. Because the server is not able to actively access the client under HTTP, the server can attach its own requests and notifications to the HTTP response. The local agreement did not make it clear how the operation was done, and the details were also an egg-sore thing.

Type hint (class hinting)

Very simple, is to add a property to represent the constructor constructor , can be used with parameters [param1,...] To initialize the object. And if the constructor is called when the object is initialized, then the corresponding properties (such as prop1 " is also added to the object, sample code:

{"__jsonclass__":["constructor", [param1,...]], "prop1": ...}

The protocol does not specifically explain this place, how to operate, how to correspond to the type of native environment, egg pain + +.

An example of multiple communication

JSON-RPC process is as follows, wherein --> represents the sending of data to the service party, <-- response on behalf of the Service party:

--> {"method": "postMessage", "params": ["Hello all!"], "id": 99}<-- {"result": 1, "error": null, "id": 99}<-- {"method": "handleMessage", "params": ["user1", "we were just talking"], "id": null}<-- {"method": "handleMessage", "params": ["user3", "sorry, gotta go now, ttyl"], "id": null}--> {"method": "postMessage", "params": ["I have a question:"], "id": 101}<-- {"method": "userLeft", "params": ["user3"], "id": null}<-- {"result": 1, "error": null, "id": 101}

Further discussion on the json-rpc1.0 specification

• About notifications

The notification mechanism can also be used for noop similar to the FTP protocol, or keep alive heartbeat mechanism in other communication protocols. During the process of specific use, periodic notifications are sent to confirm that both parties are online and can piggyback on asynchronous processing of information.

• About ID

The function of the ID field in the request, like the Correlationid in the JMS protocol, can differentiate between multiple requests, with two benefits:

1. Multiple requests can be packaged as a single request, return or return multiple responses, and the processor can differentiate multiple data by ID;
2. Can do asynchronous response, anyway I do not guarantee the order, but also according to the ID to match the original request.

In particular, with the HTTP and notification features, making the asynchronous call possible: The client sends a request 1 directly after the return, continue to send request 2, request 3 ... And so on; after processing the completion request 1, the server may return the response to the HTTP response message of request 2 or 3, or return it in one of the subsequent interactions.

• About types

Json-rpc and Xml-rpc are very types, but with the help of the schema structure of XML itself, XML-RPC defines a set of basic data types and the ability to construct complex data types based on them, so that XML-RPC can be used in more complex business interaction scenarios. While JSON-RPC uses the weak type of JS primitive, it can only represent very simple and fuzzy meta data structures, which is not conducive to complex scenes and the tool of generating code piles. If there are more efficient schema constraints, you can apply Json-rpc more broadly.

History of the Json-rpc See also: WHYNAMED-RPC-JSONRPC

Resources

• JSON data Format specification and JSON library in various languages
• 1.0 Specification Full text
• Implementation in a variety of languages

JSON-RPC 1.0 Specification Interpretation