Дата последнего изменения: 21.12.2023
Битрикс24 существует как в виде облачного сервиса, так и в виде коробочных установок на стороне клиента.
Преимущество приложений на REST в том, что они могут работать и там, и там одинаковым образом, особенно, если при разработке приложения заранее учитывать некоторые нюансы, которые могут возникнуть.
В облачном Битрикс24 всегда доступен REST "самой последней версии". Однако бывает, что обновления для коробочной версии выходят через некоторое время после появления в облаке, в связи с тем, что коробочный Битрикс24 содержит дополнительный функционал, на тестирование совместимости с которым требуется дополнительное время.
Более того, в случае с конкретной коробочной установкой нет гарантии, что владелец установил последние доступные обновления и в целом установил нужные для приложения модули Битрикс24 (например, никто не мешает в коробочном Битрикс24 совсем отключить модуль телефонии). А значит, при установке приложения нет уверенности в доступности конкретных методов REST.
Поэтому рекомендация номер 1 - в скрипте установки своего решения проверяйте перечень доступных методов и событий, обращаясь к методам methods и events, и информируйте пользователя о том, что ему нужно поставить обновления на Битрикс24
Если ваше приложение возобновляет токены авторизации при помощи refresh_token, то есть два варианта: получать новую пару токенов, делая запрос к
xxx.bitrix24.xxx/oauth/token/?grant_type=authorization_code...либо к серверу авторизации
oauth.bitrix.info/oauth/token/?grant_type=authorization_code...В случае облачного Битрикс24 одинаково хорошо сработают оба варианта, поскольку облачный Битрикс24 просто будет "прокидывать" ваш запрос к реальному серверу авторизации, однако коробочный Битрикс24 этого может и не сделать.
Поэтому рекомендация номер 2 - для обновления токенов всегда обращайтесь только напрямую к серверу авторизации. Это будет работать и для облака, и для коробки.
Обращаясь к REST-методам, ваше приложение выполняет запрос к конкретному Битрикс24. Однако события REST в любом случае проходят в ваше приложение не напрямую из конкретного Битрикс24, а через очередь событий, которая находится в облаке, даже если речь идет о коробочном Битрикс24.
Возможна ситуация, когда владелец коробочного Битрикс24 по каким-то соображениям закрыл сетевой доступ к серверу очереди событий. В этом случае, события просто не будут работать. Если вы внедряете решение, общаясь с клиентом, то нужно рекомендовать внести адрес сервера очередей в белый список.
То же самое касается и сервера авторизации. Если сетевой доступ к нему закрыт, то REST работать в коробочном Битрикс24 не будет, поскольку коробочный Битрикс24 не сможет валидировать токен, с которым к нему обращается ваше приложение.
Есть альтернативный вариант, когда вы специально для конкретного клиента на стороне его коробочного Битрикс24 подключите свой механизм авторизации и событий. Подробнее о таком способе было рассказано в докладе Максима Сидоренко: