Веб-сервис и HTTP-сервис в 1С: в чём разница

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

Путаница возникает из-за того, что оба механизма называют «сервисами» и оба решают задачу интеграции. На практике выбор между ними определяет, сколько кода придётся написать, как легко сервис будет подключаться к внешним системам и насколько гибко можно будет менять формат обмена в будущем. Ошибка на этапе выбора оборачивается либо избыточной сложностью, либо переделкой интеграции.

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

Что такое веб-сервис в 1С и как он устроен

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

Обмен данными идёт в формате XML по строгой схеме. Типы параметров привязываются к типам XDTO-пакетов, поэтому платформа сама проверяет корректность входящих сообщений: если внешняя система прислала строку вместо числа или пропустила обязательный параметр, запрос будет отклонён ещё до выполнения кода операции. Это снижает количество ошибок, но делает контракт жёстким — любое изменение структуры требует согласования с потребителями сервиса.

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

Что такое HTTP-сервис в 1С и как он устроен

HTTP-сервис — объект конфигурации, который принимает произвольные HTTP-запросы по заданному шаблону URL и отдаёт ответ, полностью сформированный кодом разработчика. Никакого автоматического контракта нет: какие методы (GET, POST, PUT, DELETE) поддерживать, какие заголовки читать и в каком формате отвечать — решает разработчик в модуле сервиса.

Типовой сценарий — REST-подобный интерфейс с обменом в JSON. Внешняя система обращается по адресу вида /hs/api/orders/123, платформа сопоставляет URL с шаблоном, извлекает параметры и вызывает обработчик. Внутри обработчика разработчик читает тело запроса, выполняет нужные действия с данными базы и формирует HTTP-ответ с кодом состояния и телом.

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

Ключевые различия: сравнение по параметрам

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

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

Как публикуются сервисы и что проверить после настройки

Публикация выполняется из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере». На вкладках настроек отдельно отмечается, публиковать ли веб-сервисы и HTTP-сервисы. Для веб-сервисов дополнительно можно публиковать WSDL-описание, для HTTP-сервисов указывается корневой URL (по умолчанию hs).

После публикации обязательна проверка доступности. Для веб-сервиса откройте в браузере адрес вида http://сервер/база/ws/ИмяСервиса?wsdl — должен отобразиться XML с описанием. Для HTTP-сервиса выполните тестовый запрос к шаблону URL и убедитесь, что приходит ожидаемый ответ, а не страница ошибки веб-сервера.

Типичные проблемы на этом этапе: не установлено расширение веб-сервера, неверные права на каталог публикации, блокировка брандмауэром, отсутствие лицензии на рабочий процесс при файловом режиме через веб-сервер. Ошибка 404 обычно означает, что публикация не выполнена или URL указан неверно, ошибка 500 — что код обработчика падает с исключением.

1. 1
   Опубликуйте базу через конфигуратор с включёнными сервисами
2. 2
   Проверьте доступность WSDL веб-сервиса или тестового URL HTTP-сервиса из браузера
3. 3
   Выполните запрос из внешнего инструмента (Postman, curl) с реальными параметрами
4. 4
   Проверьте журнал регистрации 1С на наличие ошибок при обращении
5. 5
   Убедитесь, что права пользователя, под которым идёт обращение, позволяют выполнять операции сервиса

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

Выбор определяется в первую очередь ожиданиями внешней системы. Если контрагент — другая база 1С или корпоративная система, работающая по SOAP, веб-сервис даст готовый контракт и валидацию «из коробки». Если интеграция строится с сайтом, мобильным приложением или скриптом на Python/PHP, HTTP-сервис с JSON окажется проще и для разработки, и для сопровождения.

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

Маршрут решения

Как выбрать механизм

Внешняя система требует SOAP или сама является базой 1СИспользуйте веб-сервис: WSDL и валидация сэкономят время на согласовании форматов

Интеграция с сайтом, мобильным приложением или скриптомИспользуйте HTTP-сервис с JSON — это проще для внешних разработчиков

Нужно принимать файлы, вебхуки или управлять кодами ответаТолько HTTP-сервис: веб-сервис таких сценариев не поддерживает

Критична строгая проверка структуры входящих данныхВеб-сервис с XDTO-пакетами либо HTTP-сервис с тщательной ручной валидацией

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

Опубликованный сервис — это точка входа в базу извне, поэтому вопросы безопасности нельзя откладывать. Минимальный набор: доступ только по HTTPS, отдельный пользователь 1С с урезанными правами для интеграции, аутентификация запросов (базовая, по токену в заголовке или через прокси). Публиковать сервис с правами полного доступа — прямой путь к компрометации данных.

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

Производительность и ограничения

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

Длительные операции внутри обработчика — ещё одна ловушка. Если сервис формирует тяжёлый отчёт или проводит пакет документов, запрос может превысить таймауты веб-сервера и прокси. Правильный подход — асинхронная схема: сервис принимает задание, ставит его в очередь (регистр сведений или фоновое задание) и сразу возвращает идентификатор, по которому клиент позже забирает результат.

Наконец, помните про версионирование. Для HTTP-сервисов принято включать версию в URL (/hs/api/v1/...), для веб-сервисов — создавать новые операции вместо изменения существующих. Это позволяет обновлять интеграцию, не ломая работающих потребителей.

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

Можно ли использовать веб-сервис и HTTP-сервис в одной базе одновременно?

Да, механизмы независимы и публикуются параллельно. Нередко одна и та же база отдаёт данные другой базе 1С через веб-сервис, а сайту — через HTTP-сервис. При публикации просто отметьте оба варианта в настройках публикации на веб-сервере.

Что быстрее работает — веб-сервис или HTTP-сервис?

Принципиальной разницы в скорости платформы нет, оба выполняются в сеансе 1С. HTTP-сервис с компактным JSON обычно передаёт меньше данных по сети, чем SOAP с XML-обёртками, что заметно на медленных каналах. Основная нагрузка в обоих случаях определяется кодом обработчика, а не протоколом.

Нужен ли отдельный веб-сервер для публикации сервисов?

Да, требуется IIS или Apache с установленным расширением веб-сервера платформы 1С. Веб-сервер может стоять на той же машине, что и сервер 1С, либо на отдельной. Для файловых баз публикация тоже возможна, но для промышленной эксплуатации рекомендуется клиент-серверный вариант.

Как отладить HTTP-сервис, если он возвращает ошибку?

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

Подходит ли HTTP-сервис для приёма вебхуков от внешних систем?

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

Что выбрать для новой интеграции, если внешняя система ещё не определена?

Разумный вариант — HTTP-сервис с JSON и документированным REST-подобным интерфейсом: его проще подключить практически из любой современной среды разработки. Если позже появится требование SOAP, веб-сервис можно добавить отдельно, не удаляя существующий HTTP-интерфейс.