HTTP-сервис в 1С: для чего нужен и как его применять

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

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

Механизм доступен в конфигурациях на управляемых формах и работает через веб-сервер (IIS или Apache), который перенаправляет запросы в 1С. Разработчик описывает структуру сервиса в конфигураторе, пишет обработчики на встроенном языке, а администратор публикует сервис на веб-сервере. Ниже разберём, для каких задач это применяется, как устроен механизм и как безопасно его внедрить.

Для каких задач используют HTTP-сервисы в 1С

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

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

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

Чем HTTP-сервис отличается от других способов интеграции

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

OData подходит, когда достаточно стандартного доступа к объектам базы (справочникам, документам) без особой логики: платформа сама формирует интерфейс, ничего программировать не нужно. Но как только требуется произвольная структура ответа, агрегация данных, проверки и бизнес-логика — OData уже не справляется, и нужен именно HTTP-сервис с ручными обработчиками.

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

Как устроен HTTP-сервис внутри конфигурации

HTTP-сервис создаётся в конфигураторе в ветке «Общие — HTTP-сервисы». Внутри объекта задаются шаблоны URL — адреса, по которым сервис принимает запросы, например /catalog/items/{id}. Фигурные скобки обозначают параметр пути, значение которого доступно в обработчике. К каждому шаблону привязываются методы HTTP: GET, POST, PUT, DELETE и другие.

Для каждого метода пишется обработчик на встроенном языке. Он получает объект HTTPСервисЗапрос, из которого читаются параметры, заголовки и тело запроса, выполняет нужную логику — запрос к базе, создание документа, проверки — и возвращает HTTPСервисОтвет с кодом состояния и телом, обычно в JSON. Корректные коды ответов (200, 201, 400, 404, 500) критичны: внешняя система ориентируется именно на них.

Ключевое свойство сервиса — корневой URL и признак повторного использования соединений. Ещё один важный параметр — режим работы с сеансами: по умолчанию каждый запрос создаёт новый сеанс с базой, что при высокой нагрузке приводит к расходу лицензий и памяти. Для массовых обращений настраивают пул сеансов, чтобы соединения переиспользовались.

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

Как создать и опубликовать HTTP-сервис: порядок действий

Работа делится на две части: разработку в конфигураторе и публикацию на веб-сервере. Без публикации сервис существует только в метаданных и недоступен извне — это частая причина «сервис написан, но не отвечает».

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

При публикации платформа формирует файл настроек (default.vrd), в котором перечислены публикуемые сервисы. Если сервис добавлен в конфигурацию после первой публикации, публикацию нужно выполнить заново, иначе веб-сервер о нём не узнает. На Linux с Apache дополнительно проверяют права на каталог публикации и корректность загрузки модуля веб-расширения 1С.

Для проверки удобно использовать curl или Postman: отправить запрос с нужными заголовками авторизации и посмотреть код ответа и тело. Ответ 404 чаще всего означает, что сервис не опубликован или шаблон URL не совпадает с вызываемым адресом; ответ 500 — ошибку в коде обработчика, детали которой видны в журнале регистрации.

curl -u Пользователь:Пароль -H "Content-Type: application/json" https://server/base/hs/api/catalog/items/00125

Безопасность и производительность: что учесть до запуска

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

Ни в коем случае нельзя публиковать сервис с пустым паролем или под учётной записью администратора. Все входные данные из запроса нужно валидировать: параметры URL, тело JSON, длины строк. Подстановка непроверенных данных в текст запроса к базе — прямой путь к ошибкам и потенциальным уязвимостям.

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

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

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

FAQ по HTTP-сервисам 1С