REST Route

Parameters for REST API Routes

Parameter name

Description

Default

Rest Server Name

The base address of the HTTP endpoint

n.b. please do not insert http:// or https:// here; use the Rest Schema parameter

127.0.0.1

Rest Server Port

The port of the HTTP endpoint

8080

Rest Schema

Schema to allow to distinguish between a plain or a secured connection.

Allowed values:

  • http
  • https

https

Authentication Type

HTTP Server authentication type.

Allowed values:

  • Basic
  • none

Basic

Authentication Parameters

Authentication specific parameters. For example for the Basic authentication this field should contain the credentials in the format 'user:password'

empty

Rest Action

The HTTP verb for the REST call

Allowed values:

  • GET
  • POST

POST

Rest Header Property (1)

Header property name in the Camel message where Camel Rest component will find the composed URL representing the endpoint to invoke.
For most of the use cases the default configuration works good and should not to be changed

evaluatedRestEndPoint

Rest Original Topic (1)

he name of the topic where the message was originally sent to by the device. By default it is read from the originalTopic property of the Camel message.
For most of the use cases the default configuration works good and should not to be changed

$simple{in.header.originalTopic}

Rest Message Converter

Message converter to convert the incoming message before forwarding it to the REST endpoint

Allowed values:

  • none: no message converter will be used so the message forwarded to the Rest endpoint will be the same received by the broker
  • json: the incoming message will be converted to a Kura payload then to JSON (see 1)

json

Rest Message Converter Configuration

Additional configuration that may be required by the message converter. The value of this parameter is converter-specific. The basic json converter does not require any additional configuration.

empty

Rest Url Option

Additional options to append to the Rest call url

empty

Rest Topic Matching

Describes how to map the incoming messages topics to Rest resource (see 2).
The field expects a list of rows composed by comma separated key value pair.
The key is the regex to match the incoming topics.
The value is the corresponding Rest resource.
The destination resource can contain variables recognized by the routing service (currently only ACCOUNT variable is supported).
The default value maps all the incoming topics into the ${ACCOUNT} (account name) URL. In case of multiple rows, no empty line can be inserted in between any of the rows.

.*,${ACCOUNT}

Rest Ssl Keystore Key

Client certificate (without private key, Base64 X509 UTF-8 encoded certificate)

empty

Rest Ssl Keystore Password

Client private key (Base64 key pair. supported types: PEMEncryptedKeyPair, PKCS8EncryptedPrivateKeyInfo and PEMKeyPair)

empty

Rest Ssl Keystore Cert

Password to access the key, if any

empty

Rest Ssl Truststore Cert

CA certificate (Base64 X509 UTF-8 encoded certificate)

empty

(1) The parameter has been removed starting from release 5.8.1. If specified it will be ignored.

Output Json example

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "scopeId": "AQ",
  "deviceId": "RyO9_XKGRsw",
  "clientId": "client-id-0",
  "receivedOn": 1543486113,
  "sentOn": 1543486113,
  "capturedOn": 1543486113,
  "position": {
    "longitude": 0.0,
    "latitude": 0.0,
    "precision": 50,
    "heading": 240,
    "speed": 110,
    "timestamp": 1543486113,
    "satellites": 2,
    "status": 0
  },
  "channel": {
    "semanticParts": [ "one", "two", "three" ]
  },
  "payload": {
    "metrics": {
      "metric_one": {
        "value": "string_value",
        "valueType": "string"
      },
      "metric_two": {
        "value": 123,
        "valueType": "integer"
      },
      "metric_three": {
        "value": true,
        "valueType": "boolean"
      }
    },
    "body": "VGhpcyBpcyBhIGJvZHkgY29udGVudA=="
  }
}

Topic matching example
This is a topic matching example.
Please note that the incoming message use the JMS syntax (so the topic levels are . sepated instead of / separated)

(?:[^.]*?\.){2}topic1\.topic1_1,rest_path_1
(?:[^.]*?\.){2}topic2,rest_path_2
(?:[^.]*?\.){2}topic3\.topic3_1,rest_path_3

This configuration forwards the messages for all the account's clients to different destination topics depending on 3 semantic topics:

MQTT semantic topic

HTTP Endpoint

topic1/topic1_1

/rest_path_1

topic2

/rest_path_2

topic3/topic3_1

/rest_path_3