17 января 2026 · 6 мин чтения

HTTP-сервисы в 1С: как они устроены и когда их использовать

HTTP-сервис в 1С это опубликованный на веб-сервере набор адресов, по которым внешняя система (сайт, мобильное приложение, бот, платёжный шлюз) отправляет запросы в базу и получает ответ, обычно в JSON. Его используют, когда нужен обмен в реальном времени и готового формата обмена недостаточно. Для регулярной выгрузки каталога по расписанию может хватить и файлового обмена, а вот проверка остатка или создание заказа лучше решаются через HTTP-сервис.

Из чего состоит HTTP-сервис

В конфигураторе HTTP-сервис описывается тремя уровнями.

Сам сервис с корневым адресом (например, api) и именем.
Шаблоны URL: пути вида /orders или /orders/{id}, где часть пути может быть параметром.
Методы шаблона: GET, POST, PUT, DELETE и другие, у каждого свой обработчик на встроенном языке.

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

Упрощённый пример обработчика метода GET для шаблона /products/{code}:

Функция ProductsGET(Запрос)
    Код = Запрос.ПараметрыURL.Получить("code");

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

    Данные = Новый Структура("code, name", Код, "Название из справочника");
    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Данные);
    Ответ.УстановитьТелоИзСтроки(Запись.Закрыть());

    Возврат Ответ;
КонецФункции

Пример учебный: в реальном сервисе вы ищете элемент справочника по коду, обрабатываете случай «не найден» (код 404) и не возвращаете лишние поля.

Публикация и доступность снаружи

Чтобы сервис заработал, базу нужно опубликовать на веб-сервере (чаще всего на Apache или IIS), указав, какие HTTP-сервисы доступны. Дальше возникают организационные вопросы, а не технические.

Где находится веб-сервер: внутри сети или в DMZ.
Как к нему обращается внешняя система: напрямую по интернету или через обратный прокси.
Закрыт ли он HTTPS-сертификатом, ведь без шифрования отдавать данные нельзя.
Опубликована ли вся база или только нужный сервис.

Я предпочитаю ставить перед 1С обратный прокси, который принимает запросы из интернета, проверяет заголовки, ограничивает частоту и пробрасывает только нужные пути. Прямая публикация базы наружу без такого слоя повышает риск.

Аутентификация и безопасность

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

Основные меры:

отдельный пользователь интеграции с правами только на нужные объекты;
HTTPS обязателен, пароли и токены не должны идти по открытому каналу;
ограничение по IP-адресам, если внешняя система имеет постоянные адреса;
проверка подписи запроса или секретного токена в обработчике, если запросы приходят от шлюза или стороннего сервиса;
журналирование обращений с указанием, что запрошено и чем закончилось.

Секреты не должны лежать в коде обработчиков. Храните их в защищённых настройках, а в журнал не пишите ни пароли, ни полные данные карт и персональные данные.

Когда HTTP-сервис подходит, а когда нет

HTTP-сервис хорош там, где внешней системе нужен ответ сразу:

сайт запрашивает цену и остаток при открытии карточки или оформлении заказа;
Telegram-бот отдаёт клиенту статус заказа из 1С;
платёжная система присылает уведомление об оплате, которое нужно записать в документ;
мобильное приложение курьера передаёт и получает данные по маршрутам.

А вот для массовых операций он не всегда удобен. Если нужно передать тысячи номенклатурных позиций раз в сутки, лучше пакетный обмен: файлом или порциями с контролем. HTTP-сервис при плохой реализации превратится в узкое место, нагружая базу множеством мелких запросов. Вопрос «что лучше, толкать данные или забирать по расписанию» отдельно рассмотрен в статье о webhooks и опросе по расписанию.

Проектирование адресов и формата ответа

Хороший API проще поддерживать. Несколько принципов, которые я использую.

Ресурсы называются существительными: /orders, /customers, а действие задаёт метод HTTP.
Версия в пути (/v1/orders) позволяет менять формат, не ломая старых клиентов.
Коды ответов осмысленные: 200 успешно, 400 ошибка в запросе, 401 нет доступа, 404 не найдено, 409 конфликт, 500 внутренняя ошибка.
Формат ошибки единый: код и читаемое сообщение, без трассировок и внутренних имён.
Даты передаются в одном формате (ISO 8601), суммы без неоднозначных разделителей.

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

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

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

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

Как проверять сервис

Для первых проверок хватит curl или любого клиента для HTTP-запросов.

curl -i -X GET "https://example.kz/api/v1/products/000123" \
  -H "Authorization: Bearer <токен>"

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

Версионирование и сопровождение сервиса

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

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

Где разместить логику: в 1С или снаружи

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

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

Чем HTTP-сервис отличается от веб-сервиса SOAP?

HTTP-сервис проще: вы сами определяете адреса, методы и формат данных, чаще всего JSON. Веб-сервис SOAP описывается жёстким контрактом (WSDL) и работает с XML. Для новых интеграций с сайтами и приложениями обычно удобнее HTTP-сервис, а SOAP встречается там, где его требует вторая сторона.

Нужна ли отдельная лицензия для обращений через HTTP-сервис?

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

Можно ли публиковать сервис, если база в облаке?

Можно, если облачный провайдер допускает публикацию и настройку веб-сервера. Условия зависят от провайдера, поэтому уточните их до начала разработки.

Сколько запросов выдержит HTTP-сервис?

Нет универсального числа: всё определяется железом, СУБД, сложностью обработчика и блокировками. Только нагрузочный тест на копии вашей базы даёт реалистичную оценку.

Если нужен HTTP-сервис под сайт, бот или платёжную систему, опишите задачу на странице о доработке и интеграциях 1С или напишите в Telegram.

← Все заметки Обсудить задачу