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

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

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

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

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

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

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

Обмен идёт XML-сообщениями фиксированной структуры (SOAP-конверт с заголовком и телом). Из-за этого объём трафика заметно больше, чем у лёгких JSON-запросов, а разбор XML требует дополнительных ресурсов. Для высоконагруженных сценариев это становится заметным ограничением.

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

HTTP-сервис — объект конфигурации, который принимает произвольные HTTP-запросы и обрабатывает их кодом на встроенном языке. Разработчик задаёт шаблон URL (например, /api/orders/{id}), выбирает допустимые методы (GET, POST, PUT, DELETE и другие) и сам формирует тело ответа — чаще всего JSON, но допустим любой формат: XML, двоичные данные, обычный текст.

Платформа здесь не навязывает контракт: разбор тела запроса, проверка параметров, формирование кода ответа (200, 400, 404, 500) — всё это зона ответственности разработчика. С одной стороны, это даёт свободу строить REST-подобные API, удобные для сайтов, мобильных приложений и внешних разработчиков. С другой — отсутствие автоматической валидации означает, что защиту от некорректных данных нужно писать вручную.

HTTP-сервисы легче по трафику и быстрее в обработке: JSON компактнее SOAP-конверта, а разбор его в 1С выполняется штатными средствами ЧтениеJSON и ЗаписьJSON с минимальными накладными расходами.

Ключевые отличия в одной таблице

Основные различия удобно свести по параметрам, которые реально влияют на проект:

Из таблицы видно главное противоречие: web-сервис снимает с разработчика рутину (контракт, валидация), но платит за это гибкостью и производительностью. HTTP-сервис даёт максимум контроля, но требует дисциплины: без письменной спецификации API интеграцию через полгода будет сложно поддерживать.

Как выбрать подход под конкретную задачу

Выбор определяется в первую очередь тем, кто будет вызывать сервис. Если на другой стороне — система с готовым SOAP-клиентом (например, корпоративная шина данных или 1С со стороны партнёра), web-сервис сэкономит время: внешняя команда получит WSDL и сгенерирует клиентский код автоматически.

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

Второй фактор — частота изменений. Контракт SOAP-сервиса тяжело версионировать: добавление обязательного параметра в операцию ломает всех подключённых клиентов. HTTP-сервис прощает эволюцию: новые поля в JSON-ответе не мешают старым клиентам, а новые версии API можно развести по разным шаблонам URL (/api/v1/..., /api/v2/...).

Публикация и настройка на веб-сервере

Оба механизма требуют публикации информационной базы на веб-сервере (IIS или Apache) с подключённым модулем расширения 1С. Без публикации сервисы недоступны извне — это частая причина «не работающего» сервиса у начинающих разработчиков.

Публикация выполняется из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере». В диалоге на вкладках «Web-сервисы» и «HTTP-сервисы» отмечаются объекты, которые должны быть доступны. После публикации web-сервис доступен по адресу вида http://сервер/база/ws/ИмяСервиса?wsdl (для получения WSDL), а HTTP-сервис — по адресу http://сервер/база/hs/корневойURL/....

1. 1
   Создайте в конфигураторе объект «HTTP-сервис», задайте корневой URL и шаблоны URL с методами
2. 2
   Напишите код обработчиков в модуле сервиса: разбор запроса, логика, формирование HTTPСервисОтвет
3. 3
   Убедитесь, что на сервере установлен веб-сервер (IIS или Apache) и модуль веб-расширения 1С
4. 4
   Опубликуйте базу: Администрирование → Публикация на веб-сервере, отметьте нужные HTTP-сервисы
5. 5
   Проверьте доступность: выполните тестовый запрос через браузер или curl с учётными данными
6. 6
   Проверьте права: у пользователя, под которым идёт обращение, должны быть права на объекты данных, к которым обращается обработчик

curl -u Пользователь:Пароль -X POST "http://server/base/hs/api/orders" -H "Content-Type: application/json" -d "{\"number\":\"0001\"}"

Безопасность: что обязательно учесть

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

Для сервисных вызовов следует заводить отдельного пользователя 1С с минимально необходимыми правами — только на те объекты, которые реально нужны обработчику. Частая ошибка — публикация сервиса под пользователем с полными правами «для простоты»: при утечке учётных данных злоумышленник получает полный доступ к базе.

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

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

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

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

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

Типичные ошибки при разработке и внедрении

Большинство проблем с сервисами связано не с выбором технологии, а с недочётами в реализации и эксплуатации. Знание типовых ошибок помогает избежать потерь времени на диагностику.

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

FAQ