Что выбрать для интеграции в 1С: Web-сервисы (WS) или HTTP-сервисы (HS)?

← На главную

При проектировании новых интеграций в экосистеме 1С разработчики часто сталкиваются с дилеммой: использовать классические Web-сервисы (SOAP) или современные HTTP-сервисы (REST). В этой статье мы подробно проанализируем оба подхода, разберем их технические особенности, сильные и слабые стороны, а также определим, в каких ситуациях каждый из них будет наиболее эффективным.

Понятие и архитектурные различия

Для начала разберем суть технологий. Web-сервисы (WS) в 1С базируются на протоколе SOAP. Это тяжеловесный стандарт, использующий XML для передачи данных. Его главной особенностью является наличие жесткого контракта — WSDL-описания. HTTP-сервисы (HS) реализуют архитектурный стиль REST и обычно используют JSON. Они работают напрямую с HTTP-методами (GET, POST, PUT, DELETE) и не накладывают таких строгих ограничений на структуру пакета, как SOAP.

Web-сервисы (WS): Строгая типизация и ее последствия

Рассмотрим специфику работы с Web-сервисами. Основное преимущество, которое выделяют сторонники WS, — это строгая типизация. Благодаря XDTO-пакетам, платформа 1С автоматически проверяет входящие данные на соответствие схеме. Если в схеме указано, что поле должно быть числом, передача строки вызовет ошибку еще на этапе парсинга веб-сервером.

Однако, как показывает практика, эта же особенность часто становится «бутылочным горлышком». Проанализируем основные недостатки:

Сложность доработки: Любое изменение в структуре данных (добавление нового поля) требует синхронного обновления схемы XDTO на обеих сторонах интеграции. Если одна сторона обновила WSDL, а вторая нет, обмен может полностью остановиться.
Избыточность данных: Формат XML содержит много служебной информации (пространства имен, закрывающие теги), что увеличивает размер пакета в 1.5–2 раза по сравнению с JSON.
Производительность: Процесс сериализации и десериализации через СериализаторXDTO требует больше ресурсов процессора и памяти, так как системе необходимо строить дерево объектов.
Медленное подключение: При каждом вызове (если не используется кэширование прокси) система может тратить время на получение и разбор WSDL-описания.

Рассмотрим пример того, как программисты часто обходят ограничения WS, превращая их в «псевдо-HTTP», передавая данные одной строкой:


// Пример "плохой" практики в WS, когда типизация игнорируется
Функция ВыполнитьОбмен(ДанныеВФорматеJSON)
    // Тип параметра - Строка, внутри которой упакован JSON
    Чтение = Новый ЧтениеJSON;
    Чтение.УстановитьСтроку(ДанныеВФорматеJSON);
    СтруктураДанных = ПрочитатьJSON(Чтение);
    // ... дальнейшая обработка
КонецФункции

Такой подход нивелирует все преимущества WS, оставляя только его недостатки в виде накладных расходов на SOAP-конверт.

HTTP-сервисы (HS): Гибкость и скорость разработки

Теперь разберем, почему современная разработка практически полностью перешла на HTTP-сервисы. В основе HS лежит простота. Мы работаем с объектом HTTPСервисЗапрос (например, передавая GUID клиента в заголовках) и возвращаем HTTPСервисОтвет.

Основные преимущества HTTP-сервисов:

Backward Compatibility (Обратная совместимость): Вы можете добавить новое поле в JSON-ответ сервера, и старые клиенты, которые об этом поле не знают, продолжат работать без ошибок. Это позволяет обновлять системы асинхронно.
Легкость отладки: Использование инструментов вроде Postman или Insomnia позволяет тестировать сервис без написания кода в 1С (например, при получении токена авторизации). Вы просто отправляете URL-запрос и видите текстовый ответ.
Скорость JSON: Встроенные механизмы 1С для работы с JSON (ЗаписьJSON, ЧтениеJSON) работают значительно быстрее, чем XDTO-сериализация, что позволяет быстро организовывать универсальные HTTP-сервисы.
Универсальность: Любая современная внешняя система (веб-сайт, мобильное приложение, сервис логистики или система Jira) «из коробки» умеет работать с REST API.

Посмотрим на пример реализации простого HTTP-сервиса для получения данных о номенклатуре:


Функция ПолучитьДанные(Запрос)
    ИмяНоменклатуры = Запрос.ПараметрыURL.Получить("Имя");
    
    СсылкаНаТовар = Справочники.Номенклатура.НайтиПоНаименованию(ИмяНоменклатуры);
    
    Если СсылкаНаТовар.Пустая() Тогда
        Возврат Новый HTTPСервисОтвет(404);
    КонецЕсли;
    
    Результат = Новый Структура;
    Результат.Вставить("Артикул", СсылкаНаТовар.Артикул);
    Результат.Вставить("Цена", СсылкаНаТовар.Цена);
    
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, Результат);
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть());
    Возврат Ответ;
КонецФункции

Сравнение типизации: миф и реальность

Выясним причину, по которой многие до сих пор ценят WS за типизацию. В WS тип данных проверяется на уровне платформы. В HS за валидацию отвечает программист. Однако, как отмечают эксперты, в 1С программисты привыкли к «мягкой» типизации. Часто в WS-схемах намеренно используют типы xs:anyType или просто xs:string, чтобы передать произвольные данные, что сводит на нет преимущество контроля типов.

В современных HTTP-сервисах проблема валидации решается использованием JSON Schema или просто проверкой структуры внутри кода 1С. Это дает больше контроля над тем, какую именно ошибку вернуть пользователю.

Когда все же стоит использовать Web-сервисы?

Несмотря на доминирование HTTP, существуют сценарии, где WS (SOAP) оправдан:

Интеграция с государственными ИС и банками: Многие старые системы (Меркурий, Этран, банковские шлюзы) используют SOAP как стандарт. Здесь у разработчика 1С часто нет выбора.
Обмены внутри экосистемы 1С (Legacy): В старых конфигурациях механизмы обмена (например, через планы обмена и EnterpriseData) исторически завязаны на Web-сервисы. Если система уже отлажена и работает, переводить ее на HS может быть экономически нецелесообразно.
Требование гарантированного контракта: Если интеграция происходит между разными департаментами крупной корпорации, жесткий WSDL-файл может служить юридическим и техническим «договором» между командами разработки.

Итоги и рекомендации

Проанализировав ситуацию, можно сделать следующие выводы:

Для новых интеграций (особенно 1С с внешними системами: сайтами, мобильными приложениями, облачными сервисами) однозначным выбором являются HTTP-сервисы. Они обеспечивают высокую скорость разработки, легкость масштабирования и соответствуют мировым стандартам архитектуры программного обеспечения.

Для внутренних обменов 1С-1С в стабильных, редко меняющихся системах можно продолжать использовать Web-сервисы, если вам важна автоматическая проверка типов и вы готовы мириться с некоторой «неповоротливостью» технологии XDTO.

Важный совет: Если вы выбираете HTTP-сервисы, старайтесь использовать встроенную сериализацию прикладных типов 1С в JSON, которая появилась в последних версиях платформы 8.3. Это позволит значительно сократить объем ручного кода при передаче сложных объектов.

← На главную