JSON-RPC 2.0 Specification Interpretation

The json-rpc2.0 specification was maintained by the JSON-RPC Working Group ([email protected]), published in 2010-03-26 (based on the 2009-05-24 version), and was last updated in 2013-01-04.

Overall, the 2.0 version of the JSON-RPC specification changes very small, a large change of about 3 points:

1. Parameters can be used with arrays or named parameters
2. The details of the batch request are clear.
3. The mechanism for error handling is standardized

Compatibility with version 1.0

• The implementation of the Recommendation 2.0 specification is compatible with the 1.0 protocol, but is not mandatory, if not compatible, it is recommended to give a friendly hint.
• The request and response messages are added with a parameter indicating the version number of the protocol: JSONRPC, which must be "2.0".
• Modification of Method: The method name in RPC is used to represent the methods and extensions inside the RPC, which must not be available elsewhere.
• The request parameter can use an array [参数1，参数2，，，] , or you can use named parameters {key:value} .
• The params can be omitted when the request parameter is empty.
• The ID should not normally be null, and it should not be a decimal number.
• When there is no ID in the request, it is treated as a notification. (1.0 When this is the ID null.) ）
• Request parameters must be exactly matched, including case.
• The answer must contain result or error, but two members must not be included at the same time.

Bulk Request

Finally, it's clear how this bulk request operates, which is to wrap multiple request objects in an array in a single request. example, package 5 requests:

--> [{" Jsonrpc ":" 2.0 "," method ":" Sum "," params ": [1,2,4]," id ":" 1 "}, {" JSONRP C ":" 2.0 "," Method ":" Notify_hello "," params ": [7]}, {" Jsonrpc ":" 2.0 "," method ":" Subtract "," params ": [42,23]," I D ":" 2 "}, {" foo ":" Boo "}, {" Jsonrpc ":" 2.0 "," Method ":" Foo.get "," params ": {" name ":" Myself "}," id ":" 5 "}, {"JSONRPC": "2.0", "Method": "Get_data", "id": "9"}] <--[{"Jsonrpc": "2.0", "Result": 7, "id": "1"}, {"Jsonrpc": "2.0", "result": +, "id": "2"}, {"J Sonrpc ":" 2.0 "," error ": {" code ": -32600," message ":" Invalid Request "}," id ": null}, {" Jsonrpc ":" 2.0 "," error ": { "Code": -32601, "message": "Method Not Found"}, "id": "5"}, {"Jsonrpc": "2.0", "Result": ["Hello", 5], "id": "9"} ]

The specification defines that all requests should be executed concurrently, and returns no guarantee order, and the client uses the ID to match the corresponding request and response. And as long as there is an error in the processing of the request, a unified error message is returned (that is, the failure is not distinguished, all of which fail). This design seems to be a matter of concern, but it should be cumbersome in general usage scenarios.

Error Object

The improved error mechanism is that error becomes a clearly defined object. Consists of three properties:

• Code: value, see next section error code.
• Message: Error message in string format.
• Data: Optional, a numeric value or object defined by the server side to append additional information.

Much better than the original extensive error mechanism.

Error code

The server-side error code was borrowed from XML-RPC:

Code	message	meaning
-32700	Parse Error Invalid	JSON is received by the server. An error occurred on the server while parsing the JSON text.
-32600	Invalid Request	The JSON sent is not a valid Request object.
-32601	Method not found	The method does not exist/is not available.
-32602	Invalid params	Invalid method parameter (s).
-32603	Internal Error	Internal JSON-RPC error.
-32000 to-32099	Server Error	Reserved for implementation-defined server-errors.

Resources

• 2.0 Specification Full text
• 2.0-to-1.0 improvements

JSON-RPC 2.0 Specification Interpretation