Как проверить HTTP-сервис в 1С

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

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

Ниже разобран практический порядок действий: от публикации до диагностики ошибок. Инструкция применима для платформы 1С:Предприятие 8.3 с публикацией на Apache или IIS, а также для файловой базы, тестируемой через встроенный веб-сервер.

Что подготовить перед проверкой

Прежде чем тестировать, убедитесь, что сам сервис корректно описан в конфигураторе. Откройте ветку «Общие» → «HTTP-сервисы» и проверьте три вещи: корневой URL сервиса, шаблоны URL и привязанные к ним методы (GET, POST и другие). Именно сочетание корневого URL и шаблона формирует итоговый адрес, по которому сервис будет доступен извне.

Второй обязательный элемент — пользователь, от имени которого будут выполняться запросы. У этого пользователя должны быть права на объекты, к которым обращается код обработчика: чтение справочников, запись документов и так далее. Анонимный доступ без пользователя возможен, только если это явно настроено и безопасно для вашей задачи.

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

HTTP-сервис недоступен извне, пока база не опубликована на веб-сервере. В конфигураторе откройте «Администрирование» → «Публикация на веб-сервере». Укажите имя публикации (латиницей, без пробелов), каталог и на вкладке «HTTP-сервисы» отметьте флажок «Публиковать HTTP-сервисы» — либо все, либо выборочно нужные.

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

Для быстрой локальной проверки без установки Apache или IIS можно использовать встроенный веб-сервер платформы — он запускается из режима отладки в конфигураторе. Это удобно для первичной проверки логики, но для реальной интеграции потребуется полноценная публикация.

1. 1
   Откройте конфигуратор, меню «Администрирование» → «Публикация на веб-сервере»
2. 2
   Задайте имя публикации и каталог, выберите веб-сервер (Apache/IIS)
3. 3
   На вкладке «HTTP-сервисы» отметьте нужные сервисы флажками
4. 4
   Нажмите «Опубликовать» и проверьте наличие default.vrd в каталоге
5. 5
   Перезапустите веб-сервер, если он был запущен до публикации

Формирование адреса запроса

Итоговый URL для вызова сервиса собирается из четырёх частей: адрес веб-сервера, имя публикации базы, префикс hs и путь из корневого URL и шаблона. Типовой вид: http://server/base/hs/exchange/orders, где exchange — корневой URL сервиса, а orders — шаблон.

Обратите внимание на регистр: в зависимости от веб-сервера и настроек путь может быть чувствителен к регистру символов. Если шаблон содержит параметры в фигурных скобках, например /orders/{НомерЗаказа}, то в запросе на место параметра подставляется конкретное значение, а в обработчике оно читается через свойство ПараметрыURL объекта запроса.

http://localhost/trade/hs/api/v1/goods/АБ-000123

Проверка через браузер и Postman

Самый быстрый способ проверить GET-метод — вставить URL прямо в адресную строку браузера. Если сервис требует аутентификацию, браузер покажет диалог ввода логина и пароля пользователя 1С. Успешный ответ — это код 200 и тело, которое вернул обработчик: строка, JSON или HTML.

Для методов POST, PUT, DELETE браузер не подходит — нужен инструмент вроде Postman, Insomnia или curl. В Postman создайте запрос, выберите метод, укажите URL, на вкладке Authorization выберите Basic Auth и введите логин и пароль пользователя 1С. Если обработчик ожидает тело запроса, задайте его на вкладке Body в нужном формате (обычно JSON) и добавьте заголовок Content-Type: application/json.

Тестировать стоит не только «правильный» запрос. Отправьте запрос с неверным параметром, пустым телом и неавторизованный запрос — так вы проверите, как сервис ведёт себя в нештатных ситуациях и не возвращает ли он лишние данные или технические тексты ошибок наружу.

Расшифровка кодов ответа и типичные ошибки

Код ответа — первый диагностический инструмент. Ошибка 404 означает, что сервис не найден: не опубликован, неверно указан URL или не совпал шаблон. Ошибка 401 — не пройдена аутентификация: неверный логин/пароль или не передан заголовок авторизации. Ошибка 403 — пользователь аутентифицирован, но у него нет прав на операцию.

Ошибка 500 — исключение в коде обработчика. Текст ошибки смотрите в журнале регистрации 1С (отбор по событию с именем сервиса) или в логах веб-сервера. Если запрос вообще не доходит до 1С (таймаут, отказ в соединении), проблема на уровне веб-сервера или сети, а не конфигурации.

Отладка обработчика в конфигураторе

Когда запрос доходит, но логика работает неверно, нужна отладка. В конфигураторе включите «Отладка» → «Подключение» и убедитесь, что разрешено подключение к сеансам веб-сервера. Затем включите автоматическое подключение: «Отладка» → «Автоматическое подключение» → отметьте «HTTP-сервисы».

Поставьте точку останова в обработчике метода и отправьте запрос из Postman. Выполнение остановится в конфигураторе, и вы сможете посмотреть содержимое объекта HTTPСервисЗапрос: заголовки, параметры URL, тело запроса. Это самый надёжный способ понять, что именно приходит в 1С и где логика расходится с ожиданиями.

Проверка из встроенного языка 1С

Иногда удобнее проверить сервис не внешним инструментом, а кодом 1С — например, из обработки на тестовой базе. Для этого используется объект HTTPСоединение и HTTPЗапрос: формируется запрос с тем же URL, заголовками авторизации и телом, выполняется метод, и анализируется код состояния и тело ответа.

Такой подход удобен для автоматизированных smoke-тестов: обработка последовательно вызывает все методы сервиса и фиксирует коды ответов. Это позволяет быстро убедиться после обновления конфигурации, что интеграционная точка не сломалась.

Соединение = Новый HTTPСоединение("server", 80, "Пользователь", "Пароль");
Запрос = Новый HTTPЗапрос("/trade/hs/api/v1/goods");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
	Сообщить(Ответ.ПолучитьТелоКакСтроку());
Иначе
	Сообщить("Ошибка: " + Ответ.КодСостояния);
КонецЕсли;

Безопасность при тестировании

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

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

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