Тестирование и отладка HTTP-сервиса в 1С:Предприятие

HTTP-сервис считается рабочим, когда по его адресу приходит осмысленный ответ с кодом 200, а не ошибка веб-сервера или 404. Проверка сводится к четырём точкам: опубликован ли сервис, отвечает ли URL, доходит ли запрос до кода обработчика и хватает ли прав вызывающему.

Начинать удобно от простого к сложному: сначала открыть адрес в браузере, затем подключить отладчик, потом слать запросы из Postman или cURL и смотреть журнал регистрации. Ниже — каждый шаг с конкретными путями и примерами.

С чего начать: публикация и сам объект метаданных

Сервис должен существовать в конфигурации и быть опубликован на веб-сервере. Проверьте три вещи по порядку.

1. В дереве конфигурации раскройте ветку Общие → HTTP-сервисы. У сервиса должен быть задан корневой URL, хотя бы один шаблон URL и метод с установленным обработчиком.
2. Сервис должен быть выгружен на веб-сервер. Публикация делается в Конфигураторе: Администрирование → Публикация на веб-сервере. В окне публикации на вкладке HTTP-сервисов отметьте нужный сервис галочкой либо включите публикацию всех сервисов по умолчанию.
3. Веб-сервер (Apache или IIS) должен быть запущен, а каталог публикации — доступен. После изменения состава сервисов публикацию нужно выполнить заново.

Адрес HTTP-сервиса собирается по схеме:

http://<веб-сервер>/<имя публикации>/hs/<корневой URL сервиса>/<шаблон>

Префикс hs — обязательный маркер HTTP-сервиса (у SOAP веб-сервисов он другой — ws). Корневой URL задаётся в свойствах самого сервиса, шаблон — в подчинённом объекте «Шаблон URL». Перепутанный префикс или лишний слэш — самая частая причина 404 на ровном месте.

Быстрая проверка адреса из браузера

GET-метод проще всего дёрнуть прямо из адресной строки. Вставьте собранный URL и посмотрите на результат.

• Пришёл ожидаемый ответ (JSON, XML, текст) — сервис работает, можно переходить к логике.
• Браузер спрашивает логин и пароль — публикация требует аутентификации средствами 1С. Это нормально, введите пользователя информационной базы.
• 404 Not Found — неверный адрес, сервис не опубликован или перепутан префикс hs.
• 500 или страница веб-сервера с ошибкой — запрос дошёл до платформы, но код обработчика упал. Это уже повод включать отладку и смотреть журнал.
• Ошибка подключения, сайт недоступен — проблема на уровне веб-сервера, а не 1С.

Браузер гоняет только GET-запросы без тела. Для POST, PUT и DELETE, а также для заголовков и тела запроса нужен Postman или cURL — о них ниже.

Отладка метода сервиса в Конфигураторе

Когда адрес отвечает, но результат не тот, нужно поймать выполнение в точке останова. Код HTTP-сервиса выполняется на стороне сервера, поэтому отладка настраивается чуть иначе, чем для клиентского кода.

1. Разрешите отладку. В Конфигураторе откройте Сервис → Параметры, на вкладке отладки включите разрешение подключения. Для серверной базы отладка на сервере тоже должна быть разрешена при его запуске.
2. Поставьте точку останова в модуле HTTP-сервиса — в теле метода, который обрабатывает нужный шаблон URL.
3. Подключитесь к процессу: меню Отладка → Подключение. В списке предметов отладки выберите тот, в котором выполняется сервис (для серверной базы это рабочий процесс сервера).
4. Повторите запрос из браузера или Postman. Выполнение остановится на точке останова — дальше идите по шагам клавишей F11, смотрите значения переменных в окне «Табло».

Если точка останова не срабатывает, а ответ при этом приходит, значит, запрос обрабатывает не тот метод или не тот шаблон URL. Сверьте шаблон в конфигурации с хвостом адреса, по которому вы стучитесь.

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

Запросы из Postman и cURL: методы, заголовки, авторизация

Postman и cURL дают полный контроль над запросом: метод, заголовки, тело, авторизация. Это основной инструмент, когда сервис принимает POST или отдаёт результат в зависимости от входных данных.

Через cURL простой GET с базовой аутентификацией:

curl -u Администратор:пароль \
  "http://localhost/base/hs/myservice/data"

POST с телом в формате JSON:

curl -u Администратор:пароль \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"Код":"000123","Количество":5}' \
  "http://localhost/base/hs/myservice/orders"

Чтобы увидеть не только тело, но и статус-код с заголовками ответа, добавьте ключ -i, а для полной картины запроса и ответа — -v:

curl -i -u Администратор:пароль \
  "http://localhost/base/hs/myservice/data"

Ключ -u логин:пароль отправляет заголовок Authorization: Basic, в котором логин и пароль упакованы в base64. Можно собрать заголовок и вручную:

echo -n "Администратор:пароль" | base64

Полученную строку подставьте в заголовок Authorization: Basic <строка>.

В Postman порядок такой:

• выберите метод (GET, POST, PUT, DELETE) и вставьте полный URL сервиса;
• на вкладке авторизации выберите тип Basic Auth и введите пользователя информационной базы;
• для POST на вкладке тела выберите raw и формат JSON, вставьте полезную нагрузку;
• проверьте заголовок Content-Type — он должен совпадать с тем, что ждёт метод.

Смотрите не только тело ответа, но и его статус-код, и заголовки — они сразу показывают, где сломалось.

Диагностика прав доступа и аутентификации

Коды 401 и 403 путают, хотя означают разное. 401 — платформа не поняла, кто вы: не передан логин-пароль или они неверны. 403 — вы опознаны, но вашему пользователю не разрешено дёргать этот сервис.

Проверяйте по цепочке:

1. Пользователь базы. Логин и пароль в запросе должны соответствовать существующему пользователю информационной базы. Регистр и раскладка имеют значение.
2. Право на сам HTTP-сервис. Откройте роль пользователя в Конфигураторе, на вкладке с HTTP-сервисами должно стоять право «Использование» для нужного сервиса. Нет права — будет 403.
3. Настройка аутентификации публикации. В файле default.vrd задано, как сервис проверяет пользователя: стандартная аутентификация 1С или средствами ОС. Если выбрана аутентификация ОС, базовый логин-пароль из Postman работать не будет.
4. Доступ к данным внутри метода. Даже при праве на сервис код внутри может обращаться к объектам, на которые у роли нет прав. Тогда ошибка вылезет уже из тела метода — ловится отладчиком.

Если сервис задуман открытым, без логина-пароля, в публикации настраивается анонимный доступ: в default.vrd для сервиса указывается пользователь базы, под которым исполняются анонимные вызовы. Тогда из Postman авторизацию можно не передавать — но код метода всё равно отработает под правами этого фиксированного пользователя.

Журнал регистрации: где искать следы запроса

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

Открыть журнал можно двумя способами:

• в Конфигураторе: Администрирование → Журнал регистрации;
• в режиме 1С:Предприятие: раздел Администрирование, пункт с журналом регистрации (у пользователя должно быть право на его просмотр).

Чтобы не тонуть в тысячах строк, поставьте фильтр:

• по интервалу времени — ровно на момент вашего запроса;
• по важности события — ошибки и предупреждения;
• по приложению — фоновые задания и сеансы, в которых исполняется серверный код.

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

Обработка ошибок и корректный ответ сервиса

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

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

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

Коды возврата используйте по назначению: 400 — клиент прислал кривые данные, 404 — запрошенного объекта нет, 409 — конфликт (например, дубль), 500 — упал сам сервис. Так тот, кто дёргает сервис снаружи, сразу поймёт, на чьей стороне проблема.

Сервис работает локально, но недоступен снаружи

Типичная ситуация: с сервера сервис отвечает по localhost, а с другого компьютера или из интернета — нет. Платформа и код тут ни при чём, проблема на сетевом уровне. Проверяйте по порядку.

• Адрес. Снаружи localhost не работает — нужен реальный IP или доменное имя сервера. Подставьте его в URL вместо localhost.
• Порт и файрвол. Веб-сервер слушает порт 80 (HTTP) или 443 (HTTPS). Если порт закрыт файрволом или не проброшен на маршрутизаторе, запрос не дойдёт. Проверить доступность порта можно командой telnet <сервер> 80 или curl -v.
• HTTPS и сертификат. Если публикация переведена на HTTPS, cURL к самоподписанному сертификату будет ругаться на проверку. Для теста это снимается ключом -k, но в продуктиве сертификат должен быть доверенным.
• CORS. Когда сервис дёргают из браузерного JavaScript со стороннего сайта, срабатывает политика источников. Нужно, чтобы метод возвращал заголовки Access-Control-Allow-Origin и сопутствующие, а на предварительный OPTIONS-запрос сервис отвечал корректно.

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