Чем web-сервис отличается от HTTP-сервиса в 1С и какой взять для интеграции

Web-сервис в 1С — это SOAP: строгий контракт в WSDL, типы через XDTO, сообщения в XML. HTTP-сервис — это свободный обработчик HTTP-запросов: вы сами задаёте URL, метод (GET, POST, PUT, DELETE) и формат тела, чаще всего JSON. Для новой интеграции с сайтом, мобильным приложением или внешней системой на любом современном языке в большинстве задач берут HTTP-сервис. Web-сервис оставляют там, где вторая сторона требует SOAP и WSDL.

Частое заблуждение — «HTTP-сервис быстрее, потому что он новее». Транспорт у обоих один и тот же: HTTP через веб-сервер с модулем расширения 1С. Разница в том, сколько работы делает платформа за вас и сколько свободы остаётся разработчику. Оба механизма работают в 1С 8.3, HTTP-сервисы появились в платформе 8.3.5, web-сервисы существуют с 8.1.

Как устроены оба механизма внутри платформы

И web-сервис, и HTTP-сервис — объекты конфигурации в ветке Общие дерева метаданных. Снаружи к ним обращаются через веб-сервер (Apache или IIS), на котором база опубликована. Веб-сервер передаёт запрос модулю расширения 1С, тот — серверу 1С или файловой базе, где выполняется код обработчика.

Web-сервис: контракт прежде кода

Работа начинается не с кода, а с описания типов.

1. В ветке Общие → XDTO-пакеты создаёте пакет со своим пространством имён и типами данных: «Заказ», «СтрокаЗаказа», «Результат».
2. В ветке Общие → Web-сервисы добавляете сервис, указываете URI пространства имён и подключаете пакеты.
3. Создаёте операции, у каждой — параметры и тип возвращаемого значения из XDTO-пакета.
4. В модуле сервиса пишете функцию-обработчик для каждой операции.

Платформа сама строит WSDL. Он доступен по адресу вида https://сервер/база/ws/ИмяСервиса?wsdl. Клиент на Java, C# или в другой базе 1С загружает этот файл и сразу знает все операции и типы.

HTTP-сервис: URL и метод

Здесь контракта нет, есть маршрутизация.

1. В ветке Общие → HTTP-сервисы создаёте сервис и задаёте свойство «Корневой URL», например api.
2. Добавляете шаблоны URL: /orders, /orders/{id}, /stock/{warehouse}.
3. Для каждого шаблона создаёте методы: GET, POST, PUT, DELETE и другие.
4. Обработчик получает объект HTTPСервисЗапрос и обязан вернуть HTTPСервисОтвет.

Адрес вызова — https://сервер/база/hs/api/orders/123. Что будет в теле ответа, решаете вы: JSON, XML, CSV, PDF, картинка.

Сравнение по главным признакам

Главное отличие для практика: web-сервис ловит кривые данные до вашего кода, HTTP-сервис отдаёт эту ответственность вам. Зато HTTP-сервис не заставляет описывать XDTO-пакет ради каждого нового поля.

Когда что выбирать: типовые сценарии интеграции

Выбор почти всегда диктует вторая сторона, а не вкус программиста 1С.

🔹 Берите HTTP-сервис, если:

• интеграция с сайтом, интернет-магазином, мобильным приложением;
• партнёр присылает документацию в стиле REST и примеры на JSON;
• нужно отдавать файлы: сканы, печатные формы в PDF, выгрузки;
• нужны вебхуки — внешний сервис сам «стучится» в 1С при событии;
• запросы идут из JavaScript в браузере.

🔹 Берите web-сервис, если:

• вторая сторона — корпоративная шина или система, которая работает только с WSDL;
• нужен жёсткий контракт: клиентов много, и каждый должен получать одинаково типизированные данные;
• обмен идёт между двумя базами 1С, и разработчики хотят готовый прокси-объект без ручного разбора JSON;
• интеграция уже работает на SOAP годами и не требует изменений.

🔹 Подумайте об OData, если нужно просто читать и писать справочники и документы без собственной логики. Стандартный интерфейс OData публикуется без программирования, по адресу /odata/standard.odata. Но любая бизнес-логика сверх CRUD — снова к HTTP-сервису.

Публикация на веб-сервере и защита доступа

Ни один сервис не заработает, пока база не опубликована. Публикация общая для обоих механизмов.

1. Запустите Конфигуратор от имени администратора Windows (на сервере, где стоит веб-сервер).
2. Откройте Администрирование → Публикация на веб-сервере.
3. Укажите имя публикации, веб-сервер и каталог.
4. На вкладках web-сервисов и HTTP-сервисов отметьте нужные сервисы. Флажки «Публиковать по умолчанию» включают и все будущие сервисы — для боевой базы лучше отмечать явно.
5. Нажмите «Опубликовать» и перезапустите веб-сервер, если Конфигуратор это предложит.

Настройки попадают в файл default.vrd в каталоге публикации. Там видно, какие сервисы включены и с какими параметрами. Этот файл удобно хранить в репозитории вместе с настройками сервера.

Кто имеет право вызывать сервис

Вызов идёт от имени пользователя информационной базы. Обычно используют Basic-аутентификацию: логин и пароль пользователя 1С в заголовке Authorization.

• 🔐 Заведите отдельного пользователя под каждую интеграцию, а не общего «exchange».
• 🔐 Создайте роль, где есть только право на нужный сервис и на объекты, которые он читает или пишет. Права на web-сервис и HTTP-сервис выдаются в ролях так же, как на справочники.
• 🔐 Уберите у такого пользователя интерактивный вход, чтобы под ним нельзя было открыть базу клиентом.
• 🔒 Публикуйте только через HTTPS. Basic-аутентификация без шифрования передаёт пароль фактически открытым текстом.

Не публикуйте сервисы с флажком «по умолчанию» на базу, открытую в интернет. Иначе каждый новый HTTP-сервис из обновления или расширения сразу становится доступен снаружи.

Отличие в защите одно: у HTTP-сервиса проще сделать собственную схему авторизации, например проверку токена из заголовка в начале обработчика. Это не отменяет входа под пользователем 1С: сеанс всё равно открывается от имени пользователя базы.

Данные, сериализация и скорость обработки

Скорость упирается не в протокол, а в три вещи: сериализацию, число вызовов и сеансы.

Сериализация

Web-сервис разбирает и собирает XML через XDTO. Для больших пакетов это заметная нагрузка: XML объёмнее JSON примерно в полтора-два раза на тех же данных, и каждый объект XDTO создаётся в памяти.

HTTP-сервис с JSON обычно легче. Для сериализации есть ЗаписьJSON и ЧтениеJSON, функции ЗаписатьJSON и ПрочитатьJSON (платформа 8.3.6 и новее). Простой пример обработчика GET для шаблона /orders/{id}:

Функция ЗаказGET(Запрос)

    Номер = Запрос.ПараметрыURL.Получить("id");
    Если Не ЗначениеЗаполнено(Номер) Тогда
        Возврат Новый HTTPСервисОтвет(400);
    КонецЕсли;

    Ссылка = Документы.ЗаказКлиента.НайтиПоНомеру(Номер);
    Если Ссылка.Пустая() Тогда
        Возврат Новый HTTPСервисОтвет(404);
    КонецЕсли;

    Данные = Новый Структура;
    Данные.Вставить("number", Номер);
    Данные.Вставить("date", Формат(Ссылка.Дата, "ДФ=yyyy-MM-ddTHH:mm:ss"));
    Данные.Вставить("sum", Ссылка.СуммаДокумента);

    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Данные);

    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(Запись.Закрыть());
    Возврат Ответ;

КонецФункции

Имя документа и реквизиты подставьте из своей конфигурации. Код возвращает понятные коды: 400 при пустом номере, 404 если заказа нет, 200 с JSON при успехе.

Число вызовов

Сто вызовов по одной записи всегда медленнее одного вызова на сто записей. На каждый вызов — аутентификация, получение сеанса, накладные расходы веб-сервера.

• 📦 Делайте пакетные методы: POST с массивом заказов вместо цикла по одному.
• 📄 Для выгрузок — постраничность: параметры limit и offset в строке запроса, их читают из Запрос.ПараметрыЗапроса.
• 🗂 Файлы отдавайте двоичными данными через УстановитьТелоИзДвоичныхДанных, а не в Base64 внутри JSON или XML.

Повторное использование сеансов

Открытие сеанса 1С на каждый запрос — дорогая операция. У web-сервисов и HTTP-сервисов есть свойство «Повторное использование сеансов». Если его включить, платформа держит сеансы в пуле и отдаёт их следующим запросам того же пользователя. Для интеграций с частыми короткими вызовами это даёт ощутимый выигрыш.

Отладка и тестирование интеграции

Отлаживать сервисы можно так же, как обычный код, с точками останова. Нужны два условия.

1. В публикации должна быть разрешена отладка. Это настраивается в диалоге публикации и отражается в default.vrd.
2. В Конфигураторе через меню Отладка → Подключение включите автоматическое подключение для HTTP-сервисов и web-сервисов. После этого при вызове сервиса отладчик остановится на вашей точке останова.

Чем вызывать сервисы снаружи

Пример проверки HTTP-сервиса из командной строки:

curl -u integr:пароль -H "Accept: application/json" \
  https://srv.local/trade/hs/api/orders/00000123

Вызов HTTP-сервиса из другой базы 1С:

Соединение = Новый HTTPСоединение("srv.local", 443, "integr", "Пароль", , 30,
    Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/trade/hs/api/orders/00000123");
Запрос.Заголовки.Вставить("Accept", "application/json");
Ответ = Соединение.Получить(Запрос);

Если Ответ.КодСостояния = 200 Тогда
    Чтение = Новый ЧтениеJSON;
    Чтение.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    Заказ = ПрочитатьJSON(Чтение);
    Чтение.Закрыть();
КонецЕсли;

Вызов web-сервиса через WSDL:

Определения = Новый WSОпределения("https://srv.local/trade/ws/Exchange?wsdl",
    "integr", "Пароль");
Прокси = Новый WSПрокси(Определения, "http://example.ru/exchange",
    "Exchange", "ExchangeSoap");
Прокси.Пользователь = "integr";
Прокси.Пароль = "Пароль";
Результат = Прокси.GetOrder("00000123");

URI пространства имён, имя сервиса и точки подключения берите из самого WSDL. Если WSDL не меняется, его лучше загрузить в конфигурацию как WS-ссылку: тогда при каждом вызове не нужно скачивать описание заново.

Где смотреть, что пошло не так

• 📋 Журнал регистрации базы: ошибки в обработчиках пишутся туда с именем пользователя интеграции.
• 📋 Логи веб-сервера: код 401 — неверный логин или пароль, 404 — сервис не опубликован или неверный корневой URL, 500 — исключение в коде.
• 📋 В обработчике HTTP-сервиса оборачивайте логику в Попытка … Исключение и возвращайте 500 с текстом ошибки в JSON. Клиенту проще разобрать ответ, чем голую страницу веб-сервера.

Перевод старых SOAP-интеграций и сопровождение

Работающий web-сервис не нужно переписывать только потому, что HTTP-сервисы моднее. Повод для перевода — реальная проблема: партнёр уходит с SOAP, нужно отдавать файлы, XDTO-пакеты стало трудно поддерживать при каждом новом поле.

Безопасный порядок перехода:

1. Вынесите бизнес-логику из модуля web-сервиса в общий модуль. Обработчик операции оставьте тонким: принять параметры, вызвать общий модуль, вернуть результат.
2. Создайте HTTP-сервис, который вызывает те же процедуры общего модуля. Логика одна, входов два.
3. Заложите версию в URL: /hs/api/v1/orders. Когда формат поменяется, появится /v2/, а старые клиенты продолжат работать.
4. Переведите клиентов по одному. Web-сервис держите опубликованным, пока последний клиент не уйдёт.
5. После этого снимите web-сервис с публикации, а через один-два релиза удалите из конфигурации.

Сервисы и обновления типовой конфигурации

Свой сервис в типовой конфигурации лучше делать в расширении. Web-сервисы и HTTP-сервисы можно добавлять в расширение, и тогда обновление БП, УТ или ERP не превращается в ручное сравнение и объединение. После установки расширения проверьте, что новый сервис отмечен в публикации: иначе вызов вернёт 404.

Частые вопросы