This is similar to my JSON-RPC 1.2 proposal, but:
Date: | 2007-12-15 |
---|---|
Web site: | (TODO) |
Author: | Roland Koebler (r dot koebler at yahoo dot de) |
TODO: |
|
"JSON-RPC is a lightweight remote procedure call protocol. It's designed to be simple!" [JSON-RPC 1.0]
That's good.
But unfortunately, some useful things are missing in JSON-RPC 1.0, especially named parameters and some definitions about error-messages. The JSON-RPC 1.1 Working Draft on the other side somehow overshoots the mark and makes things much more complicated. This already led to several discussions on the JSON-RPC mailinglist [1].
The goal of this document is to propose a JSON-RPC-specification which enhances JSON-RPC 1.0, adds reasonable features from the 1.1WD, but still stays simple.
[1] | The mailinglist recently moved from Yahoo to Google. It's current location is the JSON-RPC Google Group, but for older messages, you have to look into the old JSON-RPC Yahoo! Group. |
In my opinion, RPC consists of several independent parts:
Unfortunately, these parts are often not treated as independent, which results in unnecessarily complex results [2]. A RPC-specification should only define point 1 ("data structure"), and tell the user which serialization to use [3].
[2] | (Have you ever tried to run i.e. XML-RPC over Unix Domain Sockets? This does not work, because XML-RPC always uses http, although this would not be necessary.) |
[3] | Although requiring a specific serialization would not be absolutely necessary: It would also be possible to serialize XML-RPC-data-structures in JSON, or JSON-RPC-data-structures in XML. But I don't think that things like this are really useful. |
The differences are:
Named parameters added (OPTIONAL)
Reduced fields:
"version" field added: added a version-field to the Request to resolve compatibility issues with JSON-RPC 1.0.
Error-definitions added
System descriptions added
Extensions: moved "Class hinting" from the base specification to an extension.
The most important differences are:
Transport independence: This specification is transport-independent, so you can use any transport you like. This removes much of the complexity of the 1.1WD. (1.1WD required HTTP.)
Request:
Notifications: Notifications still exist (like in 1.0). Every Request without an id is a notification. (1.1WD removed Notifications.)
Parameter cleanup:
Response:
Error Object cleanup: The name member was removed, because it does not provide any information. The error-codes were defined.
Service Description: Use different service descriptions than 1.1WD, and describe them in a separate specification.
Member Sequence removed: No special member sequence is necessary. (1.1WD suggested the members of the JSON-RPC-object to be in a specific order, and allowed the server to refuse requests which do not stick to this order.)
No magic: Procedure Call Parity and Call Approximation were removed in this specification. A Service must be called exactly as specified. The server must not "guess".
JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. It uses JSON (RFC 4627) as data format, and is transport-independent. It's designed to be simple!
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Since JSON-RPC uses JSON, it shares the same type system as JSON (see http://www.json.org or RFC 4627). Whenever this document refers to any JSON type, the first letter is always capitalized: Object, Array, String, Number, True, False, Null.
All names (i.e. method-names or parameter-names) are case-sensitive.
Clients are the origin of Request objects. Servers are the origin of Response objects.
A remote procedure call is made by sending a Request to a remote service. The Request is expressed as a single JSON Object, with the following members:
A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0".
If version is missing, the server MAY handle the Request as JSON-RPC V1.0-Request.
A String containing the name of the procedure to be invoked.
Procedure names that begin with the word system followed by a period character (U+002E or ASCII 46) are reserved for system description / introspection.
A Request identifier that SHOULD be a JSON scalar (String, Number, True, False), but not Null [4].
If omitted, the Request is a Notification.
This id can be used to correlate a Response with its Request. The server MUST repeat it verbatim on the Response.
Every Request, except Notifications, MUST be replied to with a Response.
[4] | The use of Null for id in Requests is discouraged, because this specification uses an id of Null for Responses with an unknown id, and because JSON-RPC 1.0 uses an id of Null for Notifications. |
A Notification is a special Request, without id and without Response. The server MUST NOT reply to a Notification, except for "Parse error" and "Invalid Request".
Note that Notifications are unreliable, since they do not have a Response, and so you cannot detect errors (like e.g. "Invalid params.", "Internal error.", timeouts or maybe even lost packets on the wire).
Parameters for a procedure call can be specified by-position, or by-name (OPTIONAL).
by-position: params MUST be an Array, containing the parameters in the right order (like in JSON-RPC 1.0).
This MUST be supported.
by-name: params MUST be an Object, containing the parameter-names and its values. The names MUST match exactly (including case) the names defined by the formal arguments. The order of the name/value-pairs is insignificant.
This MAY be supported.
The position and name of a parameter is defined by the formal argument list of the procedure.
Mixing positional and named parameters in one call is not possible. (But could be added by an extension.)
If the formal argument list of a procedure defines a default-value for a parameter, and the Request does not specify this parameter, the server SHOULD use this default-value for this parameter.
When a remote procedure call is made, the service MUST reply with a Response (except for Notifications). The Response is expressed as a single JSON Object, with the following members:
Exactly one of result or error MUST be specified. It's not allowed to specify both or none.
For better compatibility with JSON-RPC 1.0-servers, a client MAY however accept both result and error if at least one of these is Null (like in the JSON-RPC 1.0-specification).
Note that there is no version-field. Since the Request already defines the version, there is no need of repeating this version in the Response.
If the server does not completely understand a Request (e.g. because of additional members), it MAY reject the Request (with "Invalid Request.").
When a remote procedure call fails, the Procedure Return object MUST contain the error member whose value is a JSON Object with the following members:
The error-codes -32768 .. -32000 (inclusive) are reserved for pre-defined errors. Any error-code within this range not defined explicitly below is reserved for future use. [5]
code | message | Meaning |
---|---|---|
-32700 | Parse error. | Invalid JSON. An error occurred on the server while parsing the JSON text. |
-32600 | Invalid Request. | The received JSON not a valid JSON-RPC Request. |
-32601 | Method not found. | The requested remote-procedure does not exist / is not available. |
-32602 | Invalid params. | Invalid method parameters. |
-32603 | Internal error. | Internal JSON-RPC error. |
-32099..-32000 | Server error. | Reserved for implementation-defined server-errors. |
[5] | The error-codes are the same as specified for XML-RPC at http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php |
Syntax:
--> data sent to service <-- data coming from service
Procedure Call with positional parameters:
--> {"version": "2.0", "method": "subtract", "params": [42, 23], "id": 1} <-- {"result": 19, "id": 1} --> {"version": "2.0", "method": "subtract", "params": [23, 42], "id": 2} <-- {"result": -19, "id": 2}
Procedure Call with named parameters:
--> {"version": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3} <-- {"result": 19, "id": 3} --> {"version": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4} <-- {"result": 19, "id": 4}
Notification:
--> {"version": "2.0", "method": "update", "params": [1,2,3,4,5]} --> {"version": "2.0", "method": "foobar"}
Procedure Call of non-existent procedure:
--> {"version": "2.0", "method": "foobar", "id": 10} <-- {"error": {"code": -32601, "message": "Procedure not found."}, "id": 10}
Procedure Call with invalid JSON:
--> {"version": "2.0", "method": "foobar, "params": "bar", "baz"] <-- {"error": {"code": -32700, "message": "Parse error"}, "id": null}
Procedure Call with invalid JSON-RPC:
--> [1,2,3] <-- {"error": {"code": -32600, "message": "Invalid JSON-RPC."}, "id": null} --> {"version": "2.0", "method": 1, "params": "bar"} <-- {"error": {"code": -32600, "message": "Invalid JSON-RPC."}, "id": null}
Procedure names that begin with system. are reserved (see Request (Procedure Call)) for system description / introspection, and SHOULD not be used for anything else.
The Service Descriptions are defined in a related specification.
All Service Descriptions are OPTIONAL.
There may be extensions, specified in related specification. (e.g. for: class-hinting, circular references, DateTime etc.)
All extensions are OPTIONAL.
Copyright (C) 2007 by ...
This document and translations of it may be used to implement JSON-RPC, it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way.
The limited permissions granted above are perpetual and will not be revoked.
This document and the information contained herein is provided "AS IS" and ALL WARRANTIES, EXPRESS OR IMPLIED are DISCLAIMED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.