Асинхронные события из веб-сокетов

Коннект через ws:

wss://web.tada.team/messaging/[team-uid]

Как и про соединении по HTTP API, надо передавать заголовок Token: joweipeijorw0rflhf4rwfasdf8134gr234rwf. Поскольку заголовок шлётся только один раз, при соединении, он нужен для всех событий, даже для пинга.

Если какие-то параметры (команда, токен) переданы неверно, придёт событие:

{
    "event": "server.panic",
    "params": {"code": str}
}

и сразу закроет соединение. Допустимые значения code.

Формат событий

Любое событие — это струкутра из трёх полей:

• event — название события. Чтобы не запутаться в процессе написания и чтения кода, события, которые шлёт сервер, называются server.*, а те, которые шлёт клиент — client.*.
• params — параметры события (необязательно). У разных событий разные. См. полное описание.
• confirm_id — id пакета (необязательно). Если есть, надо прислать в ответ подтверждение:

{
    "event": "server.confirm",
    "params": {"confirm_id": str}
}

О подтверждениях и confirm_id

Так выглядит обращение сервера с клиентом, когда сервер хочет получить 100% гарантию доставки:

SERVER: {"event": "server.ЧТО.УГОДНО", "confirm_id": 123456789}
CLIENT: {"event": "client.confirm", "params": {"confirm_id": 123456789}} 

И, соответственно, клиент общается с сервером:

CLIENT:  {"event": "client.ТОЖЕ.ЧТО.УГОДНО" , "confirm_id": 987654321}
SERVER: {"event": "server.confirm", "params": {"confirm_id": 987654321}} 

Если *.confirm не приходит в течении разумного времени, считается, что пакет потерялся по дороге, и его надо послать опять. И снова. И ещё.

Поле confirm_id может быть или не быть в любом пакете. Если он есть, значит противоположная сторона считает его важным, и нужно подтверждение. Если нет — значит нет.

Дополнительные параметры

?sendme

wss://web.tada.team/messaging/[team-uid]?sendme=server.roster

Сразу после коннекта сервер пошлёт событие server.roster.

Доступны события server.roster и server.time.

Часть истории чата

wss://web.tada.team/messaging/[team-uid]?sendme=server.roster,JID:message_id,JID:message_id

В примере JID - это jid чата, а message_id — последнее сообщение из чата, которое есть в наличии.

Если есть сообщения с датой позже, чем указанные, они прилетят пакетами: * не более 50 сообщений в каждом пакете * внутри одного пакета только сообщения одного чата * не более 20 пакетов из каждого чата. Т.е. максимально так можно получить 50*20 = 1000 сообщений на каждый чат. Если после сообщения с указанным message_id появилось более 1000 сообщений, то отправятся самые ранние. Остальные надо будет получить самостоятельно через API.

Вместо message_id можно указать строку "lastread" — указатель на последнее прочитанное сообщение в этом чате или на "last" — просто последние сообщения в чате.

ВНИМАНИЕ! не стоит увлекаться этой возможностью, и перечислять там все-все-все чаты из ростера. Только те, для которых нужно получить обновление как можно скорее: например, это может быть открытый в данный момент чат.

?afk

Сразу пометит сессию как AFK (приложение запущено, но пользователь его не трогает. В этом случае отправляются пуши, как и для оффлайна).

Далее

Полное описание событий WS API.