Особенности вызовов REST при изменении адреса Битрикс24

Как вы, наверное, знаете, новые облачные Битрикс24 создаются по сгенерированным адресам вида b24-xxx.bitrix24.yy. И в дальнейшем, пользователи имеют возможность изменить этот адрес в любой момент (с некоторыми ограничениями в зависимости от используемого тарифного плана).

Почему это важно иметь в виду? Если ваше приложение делает вызов REST Битрикс24 и при этом использует сохраненный на стороне приложения адрес, то может возникнуть ситуация, когда этот адрес уже не актуален.

В случае обращения по неактуальному адресу, Битрикс24 делает редирект на новый, но такой редирект нужно корректно обрабатывать в своем коде.

Скорее всего, при использовании GET-параметров в вызовах REST, вы просто ничего не заметите, но вот с POST-запросами все несколько сложнее.

В частности, если вы используете PHP и curl, то в зависимости от настроек, POST-запрос при редиректе может «магическим образом» превратиться в GET-запрос, при этом параметры, передававшиеся в POST-запросе попросту теряются.

Существуют два подхода:

1. Выполняя POST-запрос запретить редирект, получить статус запроса 302, взять из результата новый адрес и повторить POST-запрос, но уже по новому адресу. Например, так можно делать в приложениях на Python:

   response = requests.post(url, allow_redirects=False)
   if response.status_code == 302:
   	response = requests.post(response.headers['Location'])

2. Использовать опцию curl_setopt($ch, CURLOPT_POSTREDIR, 3), которая позволит обработать ситуацию с редиректом.

А если вы будете использовать для работы с REST наши SDK на PHP и Python, то там мы эти особенности работы уже учли.