JSON-RPC
- ️Mon Aug 07 2006
JSON-RPC is a remote procedure call protocol encoded in JSON. It is a very simple protocol (and very similar to XML-RPC), defining only a handful of data types and commands. In contrast to XML-RPC or SOAP, it allows for bidirectional communication between the service and the client, treating each more like peers and allowing peers to call one another or send notifications to one another. It also allows multiple calls to be sent to a peer which may be answered out of order.
Contents
History
Version | Description | Dated |
---|---|---|
1.0 | Original version Currently considered official according to [1] | 2005 |
1.1 WD | Working draft Adds named parameters, adds specific error codes, and adds introspection functions. | 2006-08-07 |
1.1 Alt | Suggestion for a simple JSON-RPC 1.1 Alternative proposal to 1.1 WD. | 2007-05-06 |
1.2 | Proposal A later revision of this document was renamed to 2.0. | 2007-12-27 |
2.0 | Specification proposal | 2009-05-24 |
2.0 (Revised) | Specification proposal | 2010-03-26 |
Usage
JSON-RPC works by sending a request to a server implementing this protocol. The client in that case is typically software wanting to call a single method of a remote system. Multiple input parameters can be passed to the remote method as an array or object, whereas the method itself can return multiple output data as well. (This depends on the implemented version.)
A remote method is invoked by sending a request to a remote service using HTTP or a TCP/IP socket (starting with version 2.0). When Using HTTP, the content-type may be defined as application/json
.[2]
All transfer types are single objects, serialized using JSON.[3] A request is a call to a specific method provided by a remote system. It must contain three certain properties:
method
- A String with the name of the method to be invoked.params
- An Array of objects to be passed as parameters to the defined method.id
- A value of any type, which is used to match the response with the request that it is replying to.
The receiver of the request must reply with a valid response to all received requests. A response must contain the properties mentioned below.
result
- The data returned by the invoked method. This must be null in case an error occured invoking the method.error
- A specified Error code if there was an error invoking the method, otherwisenull
.id
- The id of the request it is responding to.
Since there are situations, no response is needed or not even desired, notifications were introduced. A notification is similar to a request except for the id, which is not needed because no response will be returned. In this case the id
property should be omitted (Version 2.0) or be null
(Version 1.0).
Examples
In these examples, -->
denotes data sent to a service (request), while <--
denotes data coming from a service. (Although this direction often is called response in client-server computing, depending on the JSON-RPC version it does not necessarily imply answer to a request).
Version 1.0
A simple request and response:
--> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
<-- { "result": "Hello JSON-RPC", "error": null, "id": 1}
This example shows parts of a communication from an example chat application. The chat service sends notifications for each chat message the client peer should receive. The client peer sends requests to post messages to the chat and expects a positive reply to know the message has been posted.[4]
...
--> {"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}
...
Because params field is an array of objects, the following format is also ok:
{
"method": "methodnamehere",
"params": [
{
"firstparam": "this contains information of the firstparam.",
"secondparam": 1121211234,
"thirdparam": "this contains information of the thirdparam."
},
{
"fourthparam": "this is already a different object.",
"secondparam": "there can be same name fields in different objects.",
"thirdparam": "this contains information of the thirdparam."
}
],
"id": 1234
}
Version 1.1 (Working Draft)
The format of the contents of a request might be something like that shown below:
{ "version": "1.1", "method": "confirmFruitPurchase", "id": "194521489", "params": [ [ "apple", "orange", "pear" ], 1.123 ] }
The format of a response might be something like this:
{ "version": "1.1", "result": "done", "error": null, "id": "194521489" }
Version 2.0 (Specification Proposal)
Procedure Call with positional parameters:
--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}
--> {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2}
<-- {"jsonrpc": "2.0", "result": -19, "id": 2}
Procedure Call with named parameters:
--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}
--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4}
<-- {"jsonrpc": "2.0", "result": 19, "id": 4}
Notification:
--> {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5]}
--> {"jsonrpc": "2.0", "method": "foobar"}
Procedure Call of non-existent procedure:
--> {"jsonrpc": "2.0", "method": "foobar", "id": 10}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Procedure not found."}, "id": 10}
Procedure Call with invalid JSON:
--> {"jsonrpc": "2.0", "method": "foobar", "params": "bar", "baz"]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}
Procedure Call with invalid JSON-RPC:
--> [1,2,3]
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid JSON-RPC."}, "id": null}
--> {"jsonrpc": "2.0", "method": 1, "params": "bar"}
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid JSON-RPC."}, "id": null}
Implementations
- jsonrpc4j is a java implementation JSON-RPC 2.0 supporting streaming as well as HTTP servers. It also has support for spring service exporter\consumer.
- php-json-rpc is a simple PHP implementation of JSON-RPC 2.0.
- easyXDM is a library for cross-domain messaging with a built in RPC feature. The library supports all browsers by using a mix of postMessage, nix, frameElement, window.name, and FIM, and is very easy to use.
- Dojo Toolkit offers a broad support for JSON-RPC
- Pmrpc is an inter-window and Web Worker remote procedure call JavaScript library for use within HTML5 browsers. Pmrpc is an implementation of JSON-RPC using the HTML5 postMessage API for message transport.
- JSON Toolkit an implementation for Delphi
- Jayrock is a server implementation of JSON-RPC 1.0 for versions 1.1 and 2.0 of Microsoft's .NET Framework.
- As of version 2.0, XINS supports both JSON and JSON-RPC.
- qooxdoo includes a JSON-RPC implementation with optional backends in Java, PHP, Perl and Python.
- Barracuda Web Server's integrated JSON-RPC online documentation.
- JSON-RPC implementation in JavaScript includes JSON-RPC over HTTP and over TCP/IP Sockets
- JSON/XML-RPC Client and Server Implementations which abstract-away the differences between JSON-RPC and XML-RPC and permit cross-site requests.
- jabsorb - A lightweight Ajax/Web 2.0 JSON-RPC Java framework that extends the JSON-RPC protocol with additional ORB functionality such as circular references support.
- JSON-RPC implementation in Java A JavaScript to Java AJAX communications library (now merged with jabsorb.)
- Jettison - Java library
- LEWOStuff Includes Java support for JSON-RPC also with specific support for WebObjects.
- Perl implementations on the CPAN
- JsonRpc-Cpp OpenSource JSON-RPC implementation in C++
- TclSOAP Includes Tcl support for JSON-RPC in addition to SOAP and XML-RPC.
- Pyjamas contains a JSONRPC client implementation, as standard (Pyjamas is a framework where applications are written in Python but are compiled to Javascript).
- Zope 3 JSON-RPC Python based JSON RPC server and client implementation for Zope 3
- JQuery JSON-RPC Server This is a JSON-RPC server, specifically made to work with the Zend Framework JSON RPC Server. The Zend Framework JSON-RPC server is mildly off spec, and therefore this may not work with other JSON-RPC servers.
- jsonrpc2php is a PHP5 BSD'd JSON-RPC 2.0 Core class and example Server
- jsonrpclib is a JSON-RPC client module for Python.
- Tornado web server supports serving JSON-RPC using the tornadorpc plugin.
- JSON-RPC 2.0 Base is a minimal Java implementation of version 2.0 of the JSON-RPC protocol (open source).
- JSON-RPC 2.0 Shell for querying, testing and debugging remote JSON-RPC 2.0 web services (commercial).
- Synopse SQLite3 database Framework Open Source Delphi database access, User Interface generation, reporting, i18n in Client/Server AJAX/RESTful model.
- Objective-C DeferredKit includes a JSON-RPC 1.0 client.
- jsonrpcbase Minimal Python JSON-RPC 2.0 service implementation with the exception of a transport layer.
- java-json-rpc JSON-RPC 2.0 implementation for J2EE servers.
- lib-json-rpc JSON-RPC 2.0 implementation on servlet, client, javascript
The original official homepage[5] has links to more implementations.
See also
- Remote procedure call
- SOAPjr - a hybrid of SOAP and JSON-RPC
- JSON-WSP - a JSON-RPC inspired protocol with a service description specification.
References
External links
- Official JSON-RPC homepage includes a Python implementation of JSON-RPC
- JSON-RPC Google Group discussing topics of and around the protocol
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)