Message

Базовой сущностью протокола является Message. Структура Message представляет собой JSON следующего формата:

{
  "type": MessageType,
  "address": String,
  "reply_address": String?,
  "data": Any?,
  "headers": Map<String, String>
}

MessageType передается как строка и может иметь следующие значения:

send - вызов метода
ping - запрос на проверку связи
pong - ответ на запрос проверки связи
error - сообщение сервера об ошибке

Поле type служит для объявления типа передаваемого сообщения. Список поддерживаемых сообщений со временем может расширяться.

Поле address имеет два значения в рамках протокола:

В случае клиентского сообщения, данное поле требуется для идентификации сервиса (dispatcher), который будет обслуживать данное сообщение
В случае серверного сообщения, данное поле заполняется значением из поля reply_address клиентского запроса, чтобы клиентская часть могла определить, на какое свое сообщение она получила ответ.

Поле reply_address является опциональным и служит для передачи "адреса", на котором будет ожидать ответа клиентская часть. Сервер, в свою очередь, данное поле оставляет всегда в значении null и после успешной/неуспешной обработки клиентского сообщения помещает значение данного поля в address серверного сообщения.

Поле data содержит тело запроса. Тело запроса меняется в зависимости от обслуживающего сервиса, а так же исполняемой функции.

Поле headers содержит в себе дополнительную информацию, которая требуется для выполнения операции. В частности, поле headers, в случае клиентского запроса, обязано содержать поле action, в котором содержится название выполняемого метода в рамках сервиса. В случае серверного сообщения данное сообщение будет содержать значение null.

Заголовок action может иметь значение с использованием любой политики наименования, например:

getTokenBySerial
get_token_by_serial
GET_TOKEN_BY_SERIAL
GetTokenBySerial

являются полностью поддерживаемыми и валидными значения вызова одного и того же метода.

Важно: для всех запросов, кроме тех, что находятся в сервисе ik.service.app требуется передавать дополнительный заголовок sid - идентификатор текущей сессии. Таким образом гарантируется 1 активная сессия работы с сервисом. Подробнее о сессиях написано в разделе Сессии

Важно: для уменьшения передаваемых данных следует передавать minified JSON (без переносов строк, пробелов между полями и т.п.), например:

{"type":"send","address":"ik.service.token","headers":{"action":"getTokenBySerial","token":"AVQ11031010703","refresh_tokens":"true"}}

Примеры

Валидный клиентский Message:

{
  "type": "send",
  "address": "ik.service.token",
  "headers": {
    "action": "getTokenBySerial",
    "token": "AVQ11031010703",
    "refresh_tokens": "true"
  }
}

Валидный успешный серверный Message:

{
  "type": "send",
  "address": null,
  "reply_address": null,
  "data": {
    "device_id": 131010703,
    "operator_code": 5,
    "organization": "ИП Моров А.М.",
    "pin_code_length": 5,
    "puk_code_length": 8,
    "serial": "AVQ11031010703",
    "tax_number": 191832203
  },
  "headers": null
}

Валидный неуспешный серверный Message:

{
  "type": "error",
  "address": null,
  "reply_address": null,
  "data": {
    "description": "dispatcher not found",
    "name": "TSRV_DISPATCHER_NOT_FOUND"
  },
  "headers": null
}

tsrv

Message

Примеры