Основы
JID
Работа ведется в командах. Внутри команды есть контакты, задачи, групповые чаты. Контакт из одной команды не может просто так общаться с контактом из другой.
Каждый пользователь в команде имеет идентификатор вида d-<UID> . По историческим причинам он называется JID .
В скольких командах состоит пользователь, столько у него и JID . Если пользователь состоит в 3 командах, у него 3 JID . Если пользователь новый, то JID у него еще нет.
Поле is_archive
Из системы ничего не удаляется, просто выставляется флаг is_archive . Исключение: устройства.
Поля can_*
Если известно, кто запрашивает объект, у него появляются дополнительные поля can_ЧТО-НИБУДЬ . Они означают, «могу ли я, запрашивающий, делать с этим объектом ЧТО-НИБУДЬ».
Примеры:
{"can_send_message": false}в своем профиле означает, что я НЕ могу послать себе сообщение.{"can_add_to_team": true}в команде означает, что я МОГУ добавлять новых участников в команду (вероятно я администратор, а может владелец)
В реальности этих полей в базе не существует — они вычисляются на лету.
Для чего это надо: чтобы логика была по-максимуму в одном месте.
Например, мы решаем, что теперь можно слать себе сообщения. Немного изменяем сервер, и если приложения проверяли не «это я себе пишу, или не себе пишу», а тупо смотрели на флаг can_send_message , то больше никаких изменений вносить не надо: оба мобильных клиента и веб-клиент сразу меняют свою логику.
Второй пример: мы можем когда-нибудь завести новую сущность «администратор с настраиваемыми правами». При использовании флагов can_* можно про это не думать: в старых приложениях ничего не сломается.
/features.json
В корне есть файл features.json с полями, которые зависят от инсталляции. На разных нодах могут быть включены разные возможности.
Файл не является частью API. У API может меняться версия, старые версии могут отключаться, меняться способ авторизации. А этот файл будет на этом месте всё время.
Также есть обёртка features.js . Достаточно включить её как скрипт, и она создаст window.FEATURES.