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

HTTP-сервис в 1С — это механизм, который позволяет принимать и обрабатывать HTTP-запросы прямо внутри прикладного решения. Самый быстрый способ убедиться, что сервис работает, — обратиться к нему через обычный браузер. Это не требует установки Postman, curl или других инструментов и занимает считанные минуты, если публикация настроена правильно.

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

Материал рассчитан на разработчиков и администраторов 1С, которые настраивают интеграции и хотят быстро проверить доступность HTTP-сервиса без специализированных инструментов.

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

HTTP-сервис работает только через веб-сервер: файловый или клиент-серверный вариант базы без публикации отвечать на HTTP-запросы не будет. Поэтому первое условие — развёрнутый веб-сервер (IIS на Windows или Apache) с установленным модулем расширения веб-сервера 1С.

Второе условие — сам сервис должен существовать в конфигурации. Откройте конфигуратор и проверьте ветку «Общие → HTTP-сервисы»: у сервиса должен быть задан корневой URL, а внутри — хотя бы один шаблон URL с методом, обрабатывающим запрос. Для проверки в браузере удобнее всего метод GET.

Третье условие — права. У пользователя, под которым будет выполняться запрос, должны быть права на выполнение HTTP-сервиса. Если аутентификация не пройдёт, браузер покажет запрос логина и пароля или ошибку 401.

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

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

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

Для IIS после публикации убедитесь, что пул приложений работает под учётной записью с доступом к базе, а обработчик расширения 1С (wsisapi.dll или модуль для вашей версии) зарегистрирован. Для Apache проверьте, что в httpd.conf подключён модуль веб-расширения и указан путь к каталогу публикации.

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

Как сформировать правильный URL для проверки

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

http://server/base/hs/myservice/ping

Здесь server — имя или IP веб-сервера, base — имя публикации, hs — стандартный префикс HTTP-сервисов 1С, myservice — корневой URL сервиса, ping — шаблон URL. Если шаблон содержит параметры в фигурных скобках, например /orders/{number}, подставьте вместо параметра конкретное значение: /orders/000001.

Частая ошибка — перепутать префикс. Для HTTP-сервисов используется /hs/, а для веб-сервисов (SOAP) — /ws/. Если вместо hs указать ws или наоборот, сервер вернёт 404, даже если всё остальное настроено верно.

Проверка GET-запроса прямо в браузере

Вставьте сформированный URL в адресную строку браузера и нажмите Enter. Если для базы включена аутентификация, браузер покажет диалог ввода логина и пароля — введите учётные данные пользователя 1С с правами на сервис. Логин и пароль можно также передать прямо в URL в формате http://user:password@server/base/hs/myservice/ping, но делать это стоит только в тестовой среде.

Успешный результат — ответ, который формирует обработчик метода: строка, JSON или любой другой контент, который вы вернули через объект HTTPСервисОтвет. Если обработчик возвращает JSON, браузер отобразит его как текст; для удобного просмотра установите расширение-форматировщик JSON или откройте инструменты разработчика (F12) на вкладке «Сеть».

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

Функция pingGET(Запрос)
	Ответ = Новый HTTPСервисОтвет(200);
	Ответ.УстановитьТелоИзСтроки("{""status"":""ok""}");
	Ответ.Заголовки.Вставить("Content-Type", "application/json");
	Возврат Ответ;
КонецФункции

Проверка POST, PUT и DELETE из браузера

Адресная строка браузера умеет отправлять только GET-запросы, поэтому методы с телом запроса так просто не проверить. Есть три практических варианта обхода этого ограничения.

Первый — расширения браузера для отправки HTTP-запросов (например, REST-клиенты для Chrome или Firefox). Они позволяют выбрать метод, задать заголовки и тело запроса, и при этом остаются «внутри браузера». Второй — консоль инструментов разработчика: командой fetch() можно отправить любой запрос прямо со вкладки, открытой на вашем сервере.

Третий вариант — временно добавить в конфигурации GET-метод, который вызывает ту же бизнес-логику, что и POST. Это удобно на этапе отладки: проверяете логику через адресную строку, а после стабилизации оставляете только «боевой» метод. Не забудьте удалить отладочный метод перед передачей в работу — открытый GET-метод, изменяющий данные, это уязвимость.

fetch('/base/hs/myservice/orders', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({number: '000001'})
}).then(r => r.text()).then(console.log);

Как читать коды ответа и диагностировать проблемы

Код ответа — главный диагностический признак. Он показывает, на каком уровне произошёл сбой, и сужает поиск до конкретного звена: веб-сервер, платформа или код обработчика.

При ошибке 500 первым делом откройте журнал регистрации в конфигураторе: там будет текст исключения с указанием строки модуля. Если журнал пуст, а ошибка есть — сбой произошёл на уровне веб-сервера, и нужно смотреть его собственные логи (Event Viewer для IIS, error.log для Apache).

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

Самая частая ситуация — сервис опубликован, но в браузере 404. Причины почти всегда одни и те же: не тот префикс (ws вместо hs), опечатка в корневом URL, шаблон не совпадает с запрошенным путём или публикация выполнялась до добавления сервиса в конфигурацию. После любого изменения состава HTTP-сервисов публикацию нужно обновить.

Вторая группа ошибок связана с аутентификацией. Если в настройках публикации включена только аутентификация операционной системы, а вы проверяете с другого компьютера или из-под другого пользователя — получите 401. Для тестов проще включить аутентификацию по логину и паролю 1С.

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

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

Браузер хорош для быстрой проверки доступности, но для полноценной отладки удобнее специализированные инструменты. Postman, Insomnia или curl позволяют сохранять коллекции запросов, задавать любые заголовки и методы, смотреть точное время ответа и автоматизировать проверки.

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

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