Чем отличается web-сервис от HTTP-сервиса в 1С

В платформе 1С:Предприятие 8 существуют два механизма для организации интеграции по сети: web-сервисы и HTTP-сервисы. Внешне они похожи — оба публикуются на веб-сервере и принимают запросы извне, — но построены на разных принципах и решают разные задачи. Путаница между ними приводит к ошибкам проектирования: например, к попыткам передавать произвольный JSON через web-сервис или к ручной сборке SOAP-конвертов там, где достаточно простого HTTP-запроса.

Web-сервис в 1С — это реализация классического стека SOAP/WSDL. Платформа автоматически формирует описание сервиса (WSDL), сериализует данные в XML по строгой схеме и проверяет типы параметров. HTTP-сервис — это более свободный механизм, появившийся в платформе 8.3.5: разработчик сам определяет URL-шаблоны, методы (GET, POST, PUT, DELETE и другие) и формат тела запроса и ответа. Фактически HTTP-сервис позволяет строить REST-подобные API на стороне 1С.

Выбор между ними зависит от того, кто будет потребителем сервиса, какие требования предъявляются к формату данных и насколько важна строгая контрактная спецификация. Ниже разберём отличия по каждому значимому критерию и дадим практические критерии выбора.

Архитектурные различия: SOAP против REST-подхода

Web-сервис 1С построен на стандарте SOAP. Каждая операция описывается в конфигурации с указанием параметров и их типов, а платформа на основе этого описания автоматически генерирует WSDL-документ. Клиент получает WSDL, строит по нему прокси-классы и вызывает операции как обычные методы — вся работа с XML скрыта. Типы данных передаются через пакеты XDTO, что гарантирует строгую проверку структуры на обеих сторонах.

HTTP-сервис работает иначе: в нём разработчик определяет шаблоны URL (например, /products/{id}) и привязывает к ним методы HTTP. Платформа лишь передаёт в обработчик объект HTTPСервисЗапрос, из которого код сам извлекает параметры строки запроса, заголовки и тело. Никакого автоматического контракта нет — формат данных полностью на совести разработчика.

Из этого следует главное практическое различие: web-сервис — это «контрактный» подход, где стороны договариваются через формальное описание, а HTTP-сервис — «соглашательный», где договорённость фиксируется в документации, которую пишут вручную.

Сравнение по ключевым параметрам

Ниже сведены различия, которые важны при проектировании интеграции. Это не вопрос «что лучше», а набор компромиссов.

Обратите внимание на строку про объём трафика: SOAP-конверт добавляет заметные накладные расходы на каждый запрос. При высокой частоте вызовов и передаче небольших порций данных это становится ощутимым фактором в пользу HTTP-сервиса.

Как создаётся и публикуется каждый тип сервиса

Web-сервис добавляется в конфигураторе в ветке «Общие — Web-сервисы». Внутри объекта создаются операции, у каждой операции — параметры с типами значений или пакетами XDTO. В модуле web-сервиса пишутся функции-обработчики, возвращающие результат. Публикация выполняется через диалог «Администрирование — Публикация на веб-сервере», где для web-сервисов есть отдельный флаг; платформа формирует файл default.vrd с соответствующими настройками.

HTTP-сервис создаётся в ветке «Общие — HTTP-сервисы». Внутри объекта настраиваются шаблоны URL, а в каждом шаблоне — методы с обработчиками. Публикация также выполняется через файл default.vrd, но корневой URL задаётся свойством «Корневой URL» самого объекта HTTP-сервиса, поэтому несколько сервисов можно разнести по разным префиксам, например /api/catalog и /api/orders.

1. 1
   Создайте объект HTTP-сервиса в конфигураторе и задайте корневой URL
2. 2
   Добавьте шаблоны URL и методы с обработчиками в модуле сервиса
3. 3
   Настройте аутентификацию и права доступа к используемым объектам
4. 4
   Опубликуйте базу на веб-сервере с отметкой публикации HTTP-сервисов
5. 5
   Проверьте вызов из браузера или curl с корректными учётными данными

Форматы данных и работа с телом запроса

В web-сервисе формат предопределён: запрос и ответ — это XML внутри SOAP-конверта, структура которого выводится из XDTO-пакетов. Разработчик не управляет сериализацией напрямую — платформа сама преобразует значения в XML и обратно. Это удобно, пока структуры укладываются в типы XDTO, но становится ограничением, когда нужно передать, например, произвольный JSON с необязательными полями или вложенными массивами нефиксированной формы.

В HTTP-сервисе тело запроса доступно как строка или двоичные данные, и типичный приём — чтение JSON через ПрочитатьJSON с последующим обходом структуры. Ответ формируется симметрично: создаётся объект HTTPСервисОтвет, устанавливается код состояния (200, 400, 404, 500), заголовок Content-Type и тело. Именно здесь кроется и риск: платформа не проверит, что вы вернули корректный JSON или правильный код ошибки, — всё это зона ответственности кода.

Функция ПолучитьТоварGET(Запрос)
    КодТовара = Запрос.ПараметрыURL["id"];
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(СформироватьJSONТовара(КодТовара));
    Возврат Ответ;
КонецФункции

Когда выбирать web-сервис, а когда HTTP-сервис

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

HTTP-сервис выбирают для интеграции с веб-приложениями, мобильными клиентами, сайтами, системами на Python, PHP, Node.js и любыми технологиями, где стандартом де-факто является REST + JSON. Также HTTP-сервис незаменим, когда нужны нестандартные сценарии: приём файлов, вебхуки от внешних сервисов, выдача данных в специфичном формате, управление HTTP-кодами и заголовками (кэширование, CORS).

Безопасность и типичные ошибки

Оба механизма одинаково уязвимы при небрежной публикации: сервис, открытый наружу без аутентификации, даёт прямой доступ к данным базы. Минимальный набор мер — включение аутентификации на веб-сервере, отдельный пользователь 1С с узкими правами только на нужные объекты, HTTPS для шифрования трафика и ограничение доступа по IP на уровне веб-сервера или сетевого экрана, если потребителей немного.

Отдельный класс ошибок связан с кодом обработчиков. В HTTP-сервисах часто забывают обрабатывать исключения: необработанная ошибка приводит к ответу с кодом 500 и техническим текстом, раскрывающим внутренности конфигурации. Правильный подход — перехват исключений, запись в журнал регистрации и возврат управляемого кода ошибки с нейтральным описанием.

Проверка работоспособности после публикации

Для web-сервиса первичная проверка — открытие WSDL в браузере по адресу вида https://server/base/ws/ServiceName?wsdl. Если XML-описание отображается, публикация и аутентификация работают. Далее операцию вызывают через тестовый клиент (например, SoapUI) или через WS-ссылку из другой базы 1С.

HTTP-сервис проверяется прямым запросом: GET-методы — прямо из браузера, остальные — через curl, Postman или аналог. Контролируйте три вещи: код ответа, заголовок Content-Type и содержимое тела. Полезно сразу проверить и негативные сценарии — запрос без авторизации должен возвращать 401, запрос к несуществующему ресурсу — 404.

Ограничения и часто задаваемые вопросы

Оба механизма выполняются в контексте сервера 1С и создают сеансы, поэтому при высокой нагрузке упор идёт в лицензии и производительность кластера. Для тяжёлых сценариев интеграции стоит рассматривать очереди сообщений или выгрузку через файлы, а синхронные сервисы оставить для лёгких операций.