Работа с файлами в REST API Битрикс24 — та задача, где документация заканчивается ровно там, где начинаются проблемы. Официальные примеры показывают, как загрузить один файл в одно поле. А дальше выясняется, что у crm.item.update и crm.deal.update разные несовместимые форматы, что вложенный base64 через http_build_query уходит в никуда, а сервер при этом честно отвечает «result».

За год я делал файловую логику в шести проектах: перелив сделок между порталами, загрузка фотоописей с мобильного, парсинг PDF из карточек, сборка архивов, синхронизация аватаров. Везде подход получился разный.

Собрал всё в один разбор — шесть подходов с кодом и восемь граблей:

два формата файлового значения, которые нельзя смешивать, и почему при смешении затираются уже прикреплённые файлы;

тихий провал: HTTP 200, в ответе result, поле не обновилось;

useOriginalUfNames=Y, без которого UF_CRM_* молча игнорируются;

downloadUrl приходит с пустым auth= и без подстановки токена не скачивается, а при протухшем токене вместо файла отдаётся HTML-страница с кодом 200;

у одного изображения бывает несколько URL, и часть из них не работает — пришлось делать скоринг вариантов по эвристике.

В конце — таблица «что брать под какую задачу» и чеклист граблей. Двадцать блоков кода, всё из боевых проектов.

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу направлением интеграции и развитием платформы Digital Q.Integration в «Диасофт».

Недавно мы с коллегой Андреем Даниленко, ведущим разработчиком, провели вебинар, на котором рассказали про коннектор к 1С, и в комментариях попросили выложить более подробный технический разбор, что там происходит «под капотом» с точки зрения OData, и как выглядит этот сценарий на живых примерах. Здесь я делаю детальный текстовый анализ. Приглашаю всех присоединиться и при желании посмотреть запись вебинара: https://rutube.ru/video/9344562315beaaf94430d7c4de16ed74/?r=wd&p=KqHZJOTtxfoFzqSMgPuwYg

Когда несколько клиентов работают с одной записью, проблема часто скрывается не в самом запросе, а в моменте между чтением данных и их сохранением.

Разберём, как тестировать такие ситуации через последовательные и параллельные запросы, какие ответы считать корректными и почему одного успешного HTTP‑ответа недостаточно, чтобы подтвердить безопасность изменений.