При разработке интеграционных решений на платформе «1С:Предприятие 8» с использованием HTTP-сервисов разработчики часто сталкиваются с неочевидным поведением маршрутизации запросов. Мы можем составить идеальные шаблоны URL, но при отправке запроса управление передается совсем не тому методу, который мы планировали. В этой статье мы подробно разберем логику выбора шаблонов платформой, выясним истинную природу ошибок 405 Method Not Allowed и 500 Internal Server Error, а также по шагам настроим отладку для быстрого поиска проблем в коде.
Представим типичную ситуацию при проектировании API. В нашей конфигурации созданы два шаблона URL:
Echo с путем /*Номенклатура с путем /products/*Мы отправляем корректный запрос по адресу /products/some-id, ожидая, что управление будет передано второму шаблону. Однако платформа неожиданно направляет запрос в шаблон Echo. Выясним причину такого поведения.
Дело в том, что платформа 1С сопоставляет входящие URL-запросы с шаблонами последовательно сверху вниз — строго в том порядке, в котором объекты типа «Шаблон URL» расположены в дереве метаданных конфигуратора. Шаблон вида /* является универсальным (так называемый «жадный» или catch-all шаблон). Если он расположен выше специализированных шаблонов, он перехватит абсолютно любой запрос, и до нижележащих правил очередь просто не дойдет.
Для решения этой проблемы рассмотрим правила проектирования структуры HTTP-сервисов:
/products/{id}, /partners/info) в самом верху списка шаблонов в конфигураторе. Универсальные перехватчики вроде /* сдвигайте в самый низ дерева метаданных с помощью стрелок перемещения./* на корневом уровне — плохая практика. Вместо этого лучше спроектировать явные пути, например, /echo/* или /api/v1/*. Это полностью исключит случайные пересечения маршрутов.Когда мы отправляем запрос к нашему сервису, мы можем столкнуться с неприятными кодами ответов сервера. Проанализируем разницу между ними и разберем один крайне неочевидный нюанс платформы 1С.
Ошибка 405 Method Not Allowed (Метод не разрешен) означает, что запрашиваемый ресурс по указанному URL существует, но отправленный HTTP-метод (GET, POST, PUT, DELETE) не поддерживается этим ресурсом. В контексте 1С это происходит в следующих случаях:
Ошибка 500 Internal Server Error (Внутренняя ошибка сервера) возвращается, когда запрос успешно сопоставлен с шаблоном и методом, но в процессе выполнения серверного кода на стороне 1С произошла критическая ошибка (например, деление на ноль, обращение к несуществующему методу общего модуля или нехватка прав доступа).
Внимание, ловушка платформы! Иногда синтаксическая ошибка в модуле HTTP-сервиса (ошибка компиляции) приводит к тому, что платформа возвращает код 405 вместо логичной 500. Это происходит потому, что при синтаксической ошибке платформа не может корректно инициализировать сам HTTP-сервис. Веб-сервер не получает от расширения 1С информацию о доступных методах для данного адреса и некорректно рапортует клиенту, что метод не разрешен. Поэтому, получив ошибку 405, всегда в первую очередь проверяйте синтаксис ваших модулей через встроенную проверку конфигуратора!
Чтобы быстро локализовать и устранить ошибки в коде обработчиков, нам обязательно потребуется настроить отладку. Разберем три обязательных шага, без выполнения которых точка останова в коде HTTP-сервиса просто не сработает.
Шаг 1. Запуск сервера 1С в режиме отладки.
Служба сервера «1С:Предприятия» должна быть запущена с ключом отладки. Если используется классическая отладка по протоколу TCP/IP, в параметрах запуска службы в системном реестре Windows должен быть указан ключ -debug. Если используется современный HTTP-сервер отладки, параметры должны быть настроены на службу DBGS.
Шаг 2. Разрешение отладки в файле публикации default.vrd.
При публикации базы на веб-сервере (через конфигуратор или вручную) в конфигурационном файле default.vrd обязательно должен быть прописан флаг отладки. Посмотрим на пример структуры этого файла:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/MyDatabase"
ib="Srvr="MyServer";Ref="MyDatabase";">
<debug enable="true" url="tcp://localhost" />
<ws>
<point name="MyWebService" alias="ws1.1cws" enable="true"/>
</ws>
<httpServices publishByDefault="true"/>
</point>
Обратите внимание на строку <debug enable="true" url="tcp://localhost" />. Если вы публикуете базу через конфигуратор, обязательно устанавливайте флаг «Разрешить отладку» на вкладке «Дополнительные» диалога публикации.
Шаг 3. Подключение к предмету отладки в Конфигураторе.
Запустите Конфигуратор той базы, к которой обращается HTTP-запрос. Откройте меню Отладка — Подключение.... В открывшемся окне найдите раздел «Доступные предметы отладки». Убедитесь, что сеансы типа «HTTP-сервис» (или «Web-сервис») перенесены в правое окно «Подключенные предметы отладки». Если их там нет, выберите их вручную в левом списке и нажмите кнопку «Подключить».
Напомним структуру формирования ссылки для обращения к HTTP-сервисам 1С. Любой запрос должен строго соответствовать следующему шаблону:
http://<ИмяСервера>/<ИмяПубликацииБазы>/hs/<КорневойURLСервиса>/<ОтносительныйПутьШаблона>
Рассмотрим назначение каждого сегмента:
<ИмяСервера> — доменное имя или IP-адрес вашего веб-сервера (например, localhost или api.mycompany.ru).<ИмяПубликацииБазы> — имя виртуального каталога, указанное при публикации базы данных на веб-сервере./hs/ — обязательный системный префикс (HTTP Service). Веб-сервер использует его, чтобы понять, что этот запрос предназначен для обработки расширением 1С, а не является запросом веб-клиента или стандартного интерфейса OData.<КорневойURLСервиса> — значение свойства «Корневой URL», заданное в свойствах самого HTTP-сервиса в Конфигураторе.<ОтносительныйПутьШаблона> — часть пути, которая сопоставляется с конкретным шаблоном (например, products/12345).Рассмотрим правильную структуру написания метода в модуле HTTP-сервиса. Для примера напишем GET-метод получения данных о товаре:
Функция ПолучитьТовар(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
// Получаем параметры запроса из URL
ИдентификаторТовара = Запрос.ПараметрыШаблонаURL.Получить("ID");
Попытка
ДанныеТовара = Справочники.Номенклатура.НайтиПоРеквизиту("Код", ИдентификаторТовара);
Если ДанныеТовара.Пустая() Тогда
Ответ.КодСостояния = 404;
Ответ.УстановитьТелоИзСтроки("{""error"": ""Товар не найден""}");
Возврат Ответ;
КонецЕсли;
// Формируем JSON-ответ
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
СтруктураДанных = Новый Структура;
СтруктураДанных.Вставить("Наименование", ДанныеТовара.Наименование);
СтруктураДанных.Вставить("Артикул", ДанныеТовара.Артикул);
ЗаписатьJSON(ЗаписьJSON, СтруктураДанных);
СтрокаJSON = ЗаписьJSON.Закрыть();
Ответ.УстановитьТелоИзСтроки(СтрокаJSON);
Исключение
// В случае непредвиденных ошибок возвращаем 500
Ответ.КодСостояния = 500;
Ответ.УстановитьТелоИзСтроки("{""error"": """ + ОписаниеОшибки() + """}");
КонецПопытки;
Возврат Ответ;
КонецФункции
Используя данный шаблон написания обработчиков, правильно располагая шаблоны в дереве метаданных и следуя инструкциям по настройке отладки, вы сможете быстро диагностировать и предотвращать любые проблемы маршрутизации ваших интеграционных решений на платформе 1С!