Legrand / Raritan / Server Technology Xerus™ JSON-RPC API

Loading...
Searching...
No Matches
Rules and Mechanism for Mapping Xerus™-IDL to JSON-RPC

# Scope

Xerus™ devices provide a remote interface. The interface is a REST architecture and utilizes JSON-RPC version 2.0 for formatting messages sent to and received from the device. This document defines how formal Xerus™-IDL is mapped to JSON-RPC.

# Mapping Rules

## Type Mapping

IDL types are mapped to JSON value types as follows:

IDL Type | JSON Representation
--- | ---
boolean | `true` or `false`
int | number
long | number
float | number
double | number
string | string
time | number containing number of seconds since the start of the Unix epoch (midnight UTC of January 1, 1970)
enumeration | number representing the index of the enumeration value (0-based)
structure | object containing one element per structure member
vector | array
map | array of objects, each containing two elements: 'key' for the entry's key, 'value' for the entry's value.
interface | object containing two elements: 'rid' contains the object identifier, 'type' contains the most derived interface type

## Interface version Mapping

Interface versions as specified in IDL-File (e.g. `NumericSensor_1_0_1`) are not mapped to the protocol as such as interface identifiers are not directly part of any protocol message. However, the interface version is part of the type information which is sent along with object references. Clients may use type information and hence version information to select a compatible proxy for a received object reference.

See idl_versions for more details about interface versions.

Interface changes between firmware releases are documented in the file Changelog.txt.

## Method Mapping

IDL method calls are mapped to JSON-RPC as follows:

In JSON-RPC Request:

- method name: element 'method' of request object
- in-parameters: element 'params' of request object, containing an object with one element per parameter
- out-parameters: not mapped
- return value: not mapped

Example (net.Net.setNetworkConfigLan):

{
"jsonrpc": "2.0",
"method": "setNetworkConfigLan",
"params": {
"speed": 2,
"duplex": 0,
},
"id": 123
}

In JSON-RPC Response:

- method name: not mapped
- in-parameters: not mapped
- out-parameters: element 'result' of response object, containing an object with one element per parameter
- return value: special element'ret' of element 'result' of response object
- system errors or exceptions: element 'error' of response object

Example (result from devsettings.Snmp.getConfiguration):

{
"jsonrpc": "2.0",
"result": {
"v2enable": true,
"v3enable": false,
"readComm": "public",
"writeComm": "",
"sysContact": "",
"sysName": "",
"sysLocation": ""
},
"id": 456
}

# Call Execution

Xerus™-JSON-RPC uses HTTP-POST or HTTPS-POST requests. The JSON-RPC request is put into POST data, the JSON-RPC response is delivered in the HTTP/HTTPS response.

The HTTP URL includes an object reference which uniquely identifies a resource that implements a particular IDL interface. There are well-known references that must be used in initial requests. All well-known object references are defined in well_known_rids.

JSON-RPC responses may contain references to other objects. References returned by the device are "opaque", they do not use the well-known name. The 'rid' element of those opaque references must be used as URI in requests directed to the referenced resource.

# Authentication

All RPC calls must be authenticated with valid user credentials. Xerus™ supports two methods for passing those credentials:

- HTTP Basic Authentication
- Session Authentication

## Basic Authentication

For HTTP basic authentication the user name and password must be included in the `Authorization` header of every HTTP request. The contents of the header line must be the keyword `Basic` followed by a base64-encoded string containing the user name and password, separated by a colon. For instance, to authenticate a request with login/password = admin/raritan the following header must be sent:

Authorization: Basic YWRtaW46cmFyaXRhbg==

Note
  see default_creds for your product

## Session Authentication

For Session-based authentication the client contacts the session manager at `/session` to open a new session. The initial `newSession` request must be sent with basic authentication. The server generates a 128-bit session token and sends it to the client. Subsequent requests can be authenticated by including a `X-SessionToken` HTTP header with the secret session token:

X-SessionToken: 9e520dc84533342cd034b49550969e7f

The session token remains valid until the session expires or is closed. A session expires 30 seconds after the last request.

- see: session.SessionManager_2_0_0

# Bulk RPC

For complex client programs which perform a great number of requests it is not feasible to send a separate HTTP request for every JSON-RPC method call. There is a significant performance overhead, particularly when using HTTPS. To reduce that overhead it is possible to combine multiple JSON-RPC requests into a single HTTP request using the BulkRequest interface at `/bulk`.

A bulk request is performed by calling the performBulk method with a vector of resource IDs and JSON-RPC request objectss. The method returns a list of HTTP status codes and JSON-RPC response objects.

Example (sent to https://my-device/bulk):

{
"jsonrpc": "2.0",
"method": "performBulk",
"params": {
"requests": [
// First request: Firmware::getVersion()
{ "rid": "/firmware",
"json": { "jsonrpc": "2.0", "method": "getVersion", "params": {}, "id": 1 } },
// Second request: EventLog::clear()
{ "rid": "/eventlog",
"json": { "jsonrpc": "2.0", "method": "clear", "params": {}, "id": 2 } }
]
},
"id": 123
}

Response:

{
"jsonrpc": "2.0",
"result": {
"responses": [
// First response: HTTP 200 (OK), firmware version
{ "statcode": 200,
"json": { "jsonrpc": "2.0", "result": { "_ret_": "3.1.0.5-23456" }, "id": 1 } },
// Second response: HTTP 200 (OK), no return value
{ "statcode": 200,
"json": { "jsonrpc": "2.0", "result": null, "id": 2 } }
]
},
"id": 123
}

The Java language binding uses bulk RPC by default when using the asynchronous API. The Perl und Python bindings do not support bulk RPC yet.

- see: bulkrpc.BulkRequest_1_0_1