При проектировании архитектуры интеграции между «1С:Предприятие 8» и внешними системами (будь то мобильные приложения, сайты, CRM или сторонние сервисы) разработчики неизбежно сталкиваются с выбором: использовать классические Web-сервисы (SOAP) или более современные HTTP-сервисы (REST). Давайте подробно проанализируем, почему индустрия и сама платформа 1С все больше склоняются к использованию HTTP-сервисов, в чем заключается их колоссальный выигрыш при передаче тяжелых данных (например, картинок) и как упростить себе жизнь, отказавшись от жесткой типизации XDTO.
Для начала разберем фундаментальное различие в идеологии этих двух технологий. SOAP Web-сервисы ориентированы на действия (удаленный вызов процедур — RPC). В такой модели мы обращаемся к единой точке входа (Endpoint) и вызываем определенную функцию. При этом вся структура запроса строго регламентируется схемой XML.
HTTP-сервисы ориентированы на ресурсы. Каждый объект в системе (будь то номенклатура, заказ или картинка) имеет свой уникальный адрес (URI). Для выполнения операций используются стандартные методы протокола HTTP:
GET — получить данные ресурса;POST — создать новый ресурс;PUT / PATCH — обновить существующий ресурс;DELETE — удалить ресурс.Такой подход делает API интуитивно понятным, масштабируемым и соответствующим мировым стандартам веб-разработки.
Рассмотрим очень частую проблему: мобильное приложение на планшете вылетает при попытке передать большой пакет картинок через Web-сервис. Выясним причину этой проблемы.
В SOAP Web-сервисах любые передаваемые данные должны быть частью XML-документа. Поскольку XML является текстовым форматом, передать чистый бинарный файл (картинку) напрямую невозможно. Его приходится кодировать в текстовый формат Base64. Проанализируем последствия этого процесса:
Теперь рассмотрим, как эту задачу решают HTTP-сервисы. Они позволяют передавать данные в сыром бинарном виде («raw binary») напрямую в теле запроса без какого-либо кодирования. Давайте посмотрим на пример кода 1С для отправки бинарного файла клиенту:
// Пример отдачи картинки клиенту в HTTP-сервисе без лишнего кодирования
Функция ПолучитьКартинкуНоменклатуры(Запрос)
ИдентификаторКартинки = Запрос.ПараметрыURL.Получить("ID");
СсылкаНаФайл = ПолучитьПутьКФайлуНаДиске(ИдентификаторКартинки);
Если ФС.СуществуетФайл(СсылкаНаФайл) Тогда
ДвоичныеДанныеФайла = Новый ДвоичныеДанные(СсылкаНаФайл);
Ответ = Новый HTTPСервисОтвет(200);
// Указываем правильный тип содержимого
Ответ.Заголовки.Вставить("Content-Type", "image/jpeg");
// Передаем напрямую двоичные данные без Base64!
Ответ.УстановитьТелоИзДвоичныхДанных(ДвоичныеДанныеФайла);
Возврат Ответ;
Иначе
Возврат Новый HTTPСервисОтвет(404);
КонецЕсли;
КонецФункции
При таком подходе мобильное приложение получает чистый поток байтов прямо из HTTP-сокета и моментально сохраняет его на диск, не нагружая процессор парсингом XML. Для передачи сверхтяжелых пакетов (например, те самые 15 000 картинок) рекомендуется использовать технологию Multipart/Form-Data, отправляя картинки небольшими пачками (по 5–10 штук) в рамках одного запроса.
Каждый разработчик, сталкивавшийся с SOAP Web-сервисами в 1С, знает, какую боль доставляет настройка фабрики XDTO. Любое изменение в структуре данных (добавили один реквизит в документ или изменили тип поля) требует обязательного переформирования схемы, обновления WSDL-описания на клиенте и перегенерации прокси-классов. Если клиент отправит запрос по старой схеме, веб-сервер вернет жесткую ошибку разбора XML.
HTTP-сервисы в связке с форматом JSON предлагают концепцию слабой связанности (Loose Coupling). Давайте разберем по шагам, почему работать с JSON гораздо приятнее:
Давайте посмотрим на пример легкого чтения входящих данных JSON в HTTP-сервисе:
// Чтение JSON-данных из тела HTTP-запроса
ТелоСтрокой = Запрос.ПолучитьТелоКакСтроку("UTF-8");
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(ТелоСтрокой);
// Данные считываются напрямую в структуру или соответствие 1С
ДанныеЗапроса = ПрочитатьJSON(Чтение);
Чтение.Закрыть();
// Обращаемся к свойствам напрямую без мучительной типизации XDTO
ИмяНоменклатуры = ДанныеЗапроса.Наименование;
КодТовара = ДанныеЗапроса.Код;
В SOAP-сервисах все запросы всегда направляются на один единственный физический адрес (например, http://server/ws/service.1cws) методом POST. Какое именно действие нужно выполнить, сервер понимает только после того, как полностью прочитает и распарсит XML-тело запроса.
В HTTP-сервисах 1С реализован механизм шаблонов URL. Вы можете заложить параметры прямо в адресную строку, делая структуру API понятной и логичной:
GET /hs/api/v1/products/ — получить список товаров;GET /hs/api/v1/products/12345 — получить детальную информацию о товаре с кодом 12345;DELETE /hs/api/v1/products/12345 — удалить этот товар из системы.Платформа 1С автоматически сопоставляет входящий URL с настроенным шаблоном и передает параметры пути прямо в код обработчика в виде удобной структуры Запрос.ПараметрыURL.
Сторонники SOAP часто приводят в пример WSDL-схему как идеальный инструмент самодокументирования: клиентская система может прочитать WSDL и сама построить дерево вызовов. Однако в современной веб-разработке стандартом де-факто стал OpenAPI (Swagger).
Разработчик 1С может легко описать свой HTTP-сервис в формате JSON/YAML по стандарту OpenAPI. Любые современные фреймворки (Flutter, React Native, Swift, Kotlin) умеют на основе OpenAPI-файла генерировать готовый строго типизированный клиентский код. При этом вы избавляетесь от всех недостатков XML, сохраняя порядок и типизацию на стороне клиента.
Если перед вами стоит задача быстро развернуть API для интеграции без написания сложного кода, обратите внимание на альтернативу ручной разработке HTTP-сервисов — стандартный интерфейс OData (REST-интерфейс 1С). Достаточно установить одну галочку при публикации информационной базы на веб-сервере, и платформа автоматически сгенерирует полноценный REST-интерфейс ко всем объектам метаданных. Внешние системы смогут выполнять любые операции чтения и записи объектов через стандартные HTTP-запросы без написания единой строчки кода в модулях 1С!
HTTP-сервисы — это современный, производительный и гибкий инструмент интеграции. Они незаменимы при работе с мобильными приложениями и внешними веб-ресурсами благодаря экономии трафика, простоте сериализации в JSON и поддержке прямой передачи бинарных данных (без Base64). Web-сервисы (SOAP) постепенно уходят в прошлое и остаются востребованными лишь в специфических корпоративных сценариях, где строго регламентирован жесткий контракт обмена и требуется обязательная сквозная валидация схем данных на уровне веб-сервера.