You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Как вы, наверное, знаете, новые облачные Битрикс24 создаются по сгенерированным адресам вида b24-xxx.bitrix24.yy. И в дальнейшем, пользователи имеют возможность изменить этот адрес в любой момент (с некоторыми ограничениями в зависимости от используемого тарифного плана).
Почему это важно иметь в виду? Если ваше приложение делает вызов REST Битрикс24 и при этом использует сохраненный на стороне приложения адрес, то может возникнуть ситуация, когда этот адрес уже не актуален.
В случае обращения по неактуальному адресу, Битрикс24 делает редирект на новый, но такой редирект нужно корректно обрабатывать в своем коде.
Скорее всего, при использовании GET-параметров в вызовах REST, вы просто ничего не заметите, но вот с POST-запросами все несколько сложнее.
В частности, если вы используете PHP и curl, то в зависимости от настроек, POST-запрос при редиректе может «магическим образом» превратиться в GET-запрос, при этом параметры, передававшиеся в POST-запросе попросту теряются.
Существуют два подхода:
Выполняя POST-запрос запретить редирект, получить статус запроса 302, взять из результата новый адрес и повторить POST-запрос, но уже по новому адресу. Например, так можно делать в приложениях на Python:
response = requests.post(url, allow_redirects=False)
if response.status_code == 302:
response = requests.post(response.headers['Location'])
Использовать опцию curl_setopt($ch, CURLOPT_POSTREDIR, 3), которая позволит обработать ситуацию с редиректом.
Для удобства разработчиков просят добавить callable обработчик этого события
The text was updated successfully, but these errors were encountered:
юзерстори
https://dev.1c-bitrix.ru/rest_help/rest_sum/change_domen.php
Как вы, наверное, знаете, новые облачные Битрикс24 создаются по сгенерированным адресам вида b24-xxx.bitrix24.yy. И в дальнейшем, пользователи имеют возможность изменить этот адрес в любой момент (с некоторыми ограничениями в зависимости от используемого тарифного плана).
Почему это важно иметь в виду? Если ваше приложение делает вызов REST Битрикс24 и при этом использует сохраненный на стороне приложения адрес, то может возникнуть ситуация, когда этот адрес уже не актуален.
В случае обращения по неактуальному адресу, Битрикс24 делает редирект на новый, но такой редирект нужно корректно обрабатывать в своем коде.
Скорее всего, при использовании GET-параметров в вызовах REST, вы просто ничего не заметите, но вот с POST-запросами все несколько сложнее.
В частности, если вы используете PHP и curl, то в зависимости от настроек, POST-запрос при редиректе может «магическим образом» превратиться в GET-запрос, при этом параметры, передававшиеся в POST-запросе попросту теряются.
Существуют два подхода:
Выполняя POST-запрос запретить редирект, получить статус запроса 302, взять из результата новый адрес и повторить POST-запрос, но уже по новому адресу. Например, так можно делать в приложениях на Python:
response = requests.post(url, allow_redirects=False)
if response.status_code == 302:
response = requests.post(response.headers['Location'])
Использовать опцию curl_setopt($ch, CURLOPT_POSTREDIR, 3), которая позволит обработать ситуацию с редиректом.
Для удобства разработчиков просят добавить callable обработчик этого события
The text was updated successfully, but these errors were encountered: