HTTP-сервис в 1С 8.3: от постановки задачи до публикации на веб-сервере

Обновлено 07.10.2026 · 11 мин

Содержание

Чтобы создать сервис на 1С, добавьте в конфигурацию объект HTTP-сервис (ветка Общие → HTTP-сервисы), задайте корневой URL и шаблон адреса, напишите обработчик метода на встроенном языке и опубликуйте базу на веб-сервере через Администрирование → Публикация на веб-сервере. После этого внешняя система обращается к 1С по адресу вида http://сервер/база/hs/api/... и получает ответ в JSON.

Порядок одинаковый для любой конфигурации на платформе 8.3: Бухгалтерии, УТ, ЗУП или собственной разработки. Для бизнеса главное решение принимается заранее — делать сервис в расширении, чтобы не потерять обновления типовой конфигурации.

Какой сервис на 1С нужен бизнесу: три варианта

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

Платформа даёт три механизма. Выбор зависит от того, кто будет клиентом.

Механизм	Протокол и формат	Когда выбирать	Нужно ли программировать
HTTP-сервис	REST, обычно JSON	Сайт, мобильное приложение, любые современные системы	Да, обработчики методов
Веб-сервис	SOAP, XML, описание WSDL	Корпоративные системы, которые умеют только SOAP	Да, операции и XDTO-пакеты
Стандартный интерфейс OData	REST, JSON или Atom	Быстро отдать справочники и документы «как есть»	Нет, только настроить состав

💡 Для новых интеграций почти всегда берут HTTP-сервис. Он прост для внешних разработчиков: адрес, метод, JSON. SOAP имеет смысл, только если другая сторона требует WSDL.

OData удобен для чтения данных аналитиками и для прототипа. Но вы отдаёте внутреннюю структуру базы как есть, с именами реквизитов. Любое изменение конфигурации меняет и «API». Для публичного сервиса это неудобно.

Кто будет обращаться к вашему сервису?

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

Что подготовить из инфраструктуры для сервиса 1С

Сервис на 1С работает через веб-сервер. Сама платформа HTTP-запросы снаружи не принимает, их принимает Apache или IIS и передаёт в 1С через модуль расширения веб-сервера.

Что нужно:

🖥️ Веб-сервер. На Windows — IIS или Apache 2.4, на Linux — Apache 2.4.
🧩 Модули расширения веб-сервера 1С. Это компонент дистрибутива платформы, его отмечают при установке. Без него пункт публикации в Конфигураторе есть, но опубликовать некуда.
🔢 Совпадение версий. Версия модуля на веб-сервере и версия платформы сервера 1С должны совпадать. После обновления платформы обновляйте и модуль.
🔒 Сертификат для HTTPS. Basic-аутентификация передаёт пароль почти открытым текстом. Наружу сервис публикуют только по HTTPS, сертификат настраивается в самом веб-сервере.
🌐 Сетевой доступ. Открыты порты 80 или 443 до веб-сервера. Порты кластера 1С (1540, 1541 и диапазон рабочих процессов) наружу открывать не нужно, к ним обращается только веб-сервер.
👤 Пользователь базы для сервиса. Отдельный, с минимальным набором прав. Не используйте учётную запись администратора.

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

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

Как не сломать типовую конфигурацию: где разрабатывать сервис

Самый частый вопрос бизнеса: «Если мы допишем сервис, обновления 1С встанут?» Ответ зависит от того, куда вы добавите код.

Расширение конфигурации — основной путь

Для типовых конфигураций (Бухгалтерия, УТ, ЗУП) HTTP-сервис создают в расширении. Расширение подключается поверх типовой конфигурации, а сама она остаётся на поддержке. Обновления ставятся как обычно, расширение продолжает работать, если вы не завязались на удалённые объекты.

Порядок:

Откройте Конфигуратор, меню Конфигурация → Расширения конфигурации.
Добавьте новое расширение, дайте ему понятное имя, например ИнтеграцияССайтом.
Откройте конфигурацию расширения и в ветке Общие → HTTP-сервисы добавьте сервис.
Справочники и регистры, которые нужны сервису, заимствовать не обязательно: код расширения видит объекты основной конфигурации.

💡 Проверьте в свойствах расширения флаг безопасного режима. В безопасном режиме часть операций запрещена. Если сервис будет писать в базу или работать с файлами, снимите флаг осознанно и только для своего проверенного расширения.

Доработка основной конфигурации

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

Инструменты

Достаточно Конфигуратора. Если сервис большой и над ним работают несколько человек, удобнее 1С:Enterprise Development Tools и хранилище или Git. Для проверки запросов пригодятся curl или Postman.

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

До кода спроектируйте контракт сервиса: адреса, методы и формат ответов. Именно его увидит внешний разработчик.

Адрес HTTP-сервиса 1С собирается из частей:

https://api.company.ru/trade/hs/shop/v1/item/A-1024
        └ веб-сервер  └ публикация └ корневой URL └ шаблон

trade — имя публикации базы на веб-сервере;
hs — постоянная часть, означает HTTP-сервисы;
shop — корневой URL сервиса (свойство объекта);
/v1/item/{article} — шаблон URL, в фигурных скобках параметр.

Правила, которые экономят переделки:

📌 Версия в адресе. /v1/ в шаблоне позволит позже выпустить /v2/ и не сломать старых клиентов.
📌 Один шаблон — один ресурс. /item/{article} для товара, /order для заказа. Методы GET читают, POST создают.
📌 Коды ответов HTTP. 200 — успех, 400 — плохие данные от клиента, 404 — не найдено, 500 — сбой у вас. Клиенту проще разбирать код, чем текст ошибки.
📌 Внешние идентификаторы. Отдавайте артикул или код, а не внутреннюю ссылку 1С. Клиенту она ничего не говорит.
📌 Один формат дат и чисел. Даты в ISO 8601, числа с точкой. Сериализатор JSON платформы делает это сам, если писать через ЗаписатьJSON.

Отдельно решите, нужна ли синхронная работа. Если операция тяжёлая (например, перепровести сотню документов), сервис должен сразу ответить «принято» и поставить задачу в фоновое задание. Иначе клиент отвалится по тайм-ауту.

Пошаговая разработка HTTP-сервиса и проверка

Пример: сайт запрашивает карточку товара по артикулу. Работаем в расширении.

Шаг 1. Создайте сервис и шаблон

В ветке HTTP-сервисы добавьте объект Shop, свойство «Корневой URL» — shop.
На вкладке шаблонов URL добавьте шаблон Item со строкой /v1/item/{article}.
Внутри шаблона добавьте метод GET и создайте для него обработчик.

Шаг 2. Напишите обработчик

Конфигуратор создаст функцию в модуле сервиса. Параметр Запрос — входящий HTTP-запрос, функция возвращает ответ.

Функция ItemGET(Запрос)

    Артикул = Запрос.ПараметрыURL["article"];
    Товар = Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", Артикул);

    Если Товар.Пустая() Тогда
        Возврат ОтветJSON(404, Новый Структура("error", "Товар не найден"));
    КонецЕсли;

    Данные = Новый Структура;
    Данные.Вставить("article", Артикул);
    Данные.Вставить("name", Строка(Товар.Наименование));

    Возврат ОтветJSON(200, Данные);

КонецФункции

Функция ОтветJSON(КодСостояния, Данные)

    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Данные);

    Ответ = Новый HTTPСервисОтвет(КодСостояния);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(Запись.Закрыть(), КодировкаТекста.UTF8);
    Возврат Ответ;

КонецФункции

Для метода POST тело запроса читают так: Текст = Запрос.ПолучитьТелоКакСтроку();, затем через ЧтениеJSON и ПрочитатьJSON превращают его в структуру. Всё, что пришло извне, проверяйте: тип, обязательные поля, длину строк.

⚠️ Оборачивайте запись в базу в Попытка … Исключение. При ошибке пишите подробности в журнал регистрации через ЗаписьЖурналаРегистрации, а клиенту возвращайте код 500 и короткое сообщение без внутренних деталей.

Шаг 3. Настройте повторное использование сеансов

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

Шаг 4. Обновите расширение в базе

Сохраните расширение и выполните «Обновить конфигурацию базы данных» (F7). Если менялась основная конфигурация, понадобится монопольный доступ для обновления структуры — планируйте это на нерабочее время.

Шаг 5. Проверьте на тестовой копии

Тестируйте не на рабочей базе, а на копии. Пошлите запрос:

curl -u site_api:пароль https://test.company.ru/trade/hs/shop/v1/item/A-1024

Проверьте три сценария: существующий артикул (ответ 200), несуществующий (404), запрос без логина (401). Если пишущий метод создаёт документы, проверьте повторную отправку того же заказа: сервис не должен создать дубль. Для этого клиент передаёт свой номер заказа, а вы ищете его перед созданием.

Публикация сервиса 1С на веб-сервере

Публикацию делают на том компьютере, где стоит веб-сервер. Конфигуратор нужно запустить от имени администратора Windows, иначе он не сможет записать файлы и настройки веб-сервера.

Через Конфигуратор

Администрирование → Публикация на веб-сервере.
Укажите имя публикации (trade), тип веб-сервера и каталог.
На вкладке HTTP-сервисов отметьте ваш сервис. Остальное, что не нужно наружу (веб-клиент, OData, веб-сервисы), лучше выключить.
Нажмите «Опубликовать». Для Apache после публикации перезапустите службу веб-сервера.

⚠️ Перезапуск Apache или IIS обрывает все текущие подключения через этот веб-сервер, включая пользователей веб-клиента. Делайте его в согласованное окно.

Через командную строку

На сервере без графического интерфейса используют утилиту webinst из каталога bin платформы:

webinst -publish -apache24 -wsdir trade -dir /var/www/trade -connstr "Srvr=srv1c;Ref=trade;" -confpath /etc/apache2/apache2.conf

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

После публикации снова пройдите проверки curl, теперь по боевому адресу и по HTTPS.

Перед тем как отдать адрес внешнему разработчику

Сервис отвечает по HTTPS, по HTTP закрыт или перенаправлен
Отдельный пользователь с минимальными правами создан и пароль передан защищённо
Лишнее в публикации выключено: веб-клиент, OData, ненужные сервисы
Проверены ответы 200, 401, 404 и повторная отправка того же заказа
Описание контракта: адреса, методы, поля, коды ошибок
Указан контакт, куда сообщать о сбоях

Выполнено: 0 / 6

Ошибки при запуске сервиса 1С и как их разобрать

Ответ сервиса по коду HTTP сразу подсказывает, где искать.

Диагностика: выберите симптом

Ещё три ошибки уровня проекта, которые видны не сразу:

❌ Сервис работает от администратора. При взломе пароля у злоумышленника полный доступ к базе. Права пользователя сервиса — только на нужные объекты.
❌ Нет журнала. Через месяц клиент говорит «заказ ушёл, а у вас его нет», и проверить нечем. Пишите в журнал регистрации входящие запросы на запись с внешним номером.
❌ Контракт меняют без версии. Переименовали поле в ответе — сайт упал. Новый формат выпускайте как /v2/, старый держите, пока клиенты не перейдут.

Сопровождение и развитие сервиса на 1С

Сервис — это не разовый проект. После запуска у него появляется регулярная работа.

Обновления платформы. При переходе на новую версию платформы обновите модули расширения веб-сервера до той же версии и перезапустите веб-сервер. Это самая частая причина внезапной ошибки 500 после планового обновления.

Обновления конфигурации. После установки релиза типовой конфигурации проверьте, что расширение применилось без ошибок, и прогоните тестовые запросы curl. Если релиз изменил реквизит, который читает сервис, Конфигуратор покажет ошибку при проверке расширения.

Мониторинг. Минимум — внешняя проверка раз в несколько минут: запрос к лёгкому методу вроде /v1/ping, который возвращает 200. Если ответа нет, уведомление уходит администратору.

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

Документация. Держите описание контракта рядом с кодом: адреса, поля, коды ошибок, пример запроса. Следующий разработчик разберётся за час, а не за неделю.

Можно ли сделать сервис на 1С без программиста?

Частично. Стандартный интерфейс OData публикуется без кода, нужно только задать состав объектов и опубликовать базу. HTTP- и веб-сервисы требуют программирования на встроенном языке.

Подойдёт ли файловая база для HTTP-сервиса?

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

Как вызвать чужой REST-сервис из 1С, а не опубликовать свой?

Для исходящих запросов используют объекты HTTPСоединение и HTTPЗапрос. Публикация на веб-сервере для этого не нужна.

Можно ли сделать сервис без авторизации?

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

Сколько стоит разработка сервиса на 1С?

Ориентировочно простой сервис на чтение в 2–3 метода занимает у программиста 1–3 рабочих дня с тестами и публикацией. Сервис с записью документов, проверками и журналом — от одной до нескольких недель.

Помогла статья?