Разработка и интеграция веб-сервисов — одно из наиболее востребованных направлений в современной экосистеме решений на платформе 1С:Предприятие. Тем не менее, начинающие разработчики часто сталкиваются с непониманием базовых принципов работы сетевых протоколов. Типичная ситуация: вы создали свой первый HTTP-сервис в 1С, настроили публикацию на веб-сервере, успешно протестировали отправку запросов в специализированной утилите (например, Postman) и даже смогли поймать точку останова в конфигураторе. Однако при попытке ввести тот же самый URL-адрес в адресную строку веб-браузера вы видите пустой экран или ошибку. Давайте детально проанализируем, почему так происходит, разберем разницу между методами запросов и научимся правильно отлаживать и проектировать интеграционные механизмы.
Для того чтобы понять, почему обычный интернет-браузер не выводит результат выполнения вашего HTTP-сервиса, давайте обратим внимание на протокол HTTP и принципы работы адресной строки. Любой стандартный браузер (Google Chrome, Яндекс.Браузер, Mozilla Firefox) при вводе URL-адреса в строку навигации и нажатии клавиши Enter инициализирует и отправляет исключительно GET-запрос.
Метод GET предназначен для получения информации с сервера. Он не имеет тела запроса, а все параметры передаются непосредственно в самом URL-адресе (так называемые Query Parameters). В то же время метод POST служит для отправки данных на сервер (например, создание нового элемента или передача сложной структуры JSON в теле запроса). Запрос POST обязательно содержит тело, в котором передаются структурированные данные.
Если ваш HTTP-сервис в 1С настроен на обработку метода POST (как в коде функции getdatapost), то при отправке GET-запроса из адресной строки браузера произойдет одно из двух:
Запрос.ПолучитьТелоКакСтроку(). Поскольку браузер отправил пустой GET-запрос без тела, переменная JSON окажется пустой строкой, парсер 1С вызовет исключение, и сервис вернет ошибку преобразования.В приложении Postman или Fiddler вы можете вручную переключать типы запросов (GET, POST, PUT, DELETE), добавлять заголовки и заполнять вкладку Body (тело запроса). Браузер «из коробки» делать этого в адресной строке не умеет.
Если вам критически важно протестировать работу именно вашего POST-сервиса непосредственно в веб-браузере без использования сторонних утилит, мы можем использовать встроенную консоль разработчика. Современные браузеры поддерживают технологию API Fetch, которая позволяет программно генерировать любые типы HTTP-запросов.
Выполним следующие шаги для тестирования:
fetch('http://localhost/http/hs/ServIIS/getdata', {
method: 'POST',
headers: {
'Content-Type': 'application/json;charset=utf-8'
},
body: JSON.stringify({ inn: "7701234567" })
})
.then(response => response.json())
.then(data => console.log('Ответ от 1С получен:', data))
.catch(error => console.error('Произошла ошибка:', error));
Этот скрипт сформирует полноценный асинхронный POST-запрос с телом в формате JSON, отправит его на ваш веб-сервер и выведет структурированный ответ прямо в окно консоли. Это отличный способ быстрой отладки фронтенд-взаимодействия без переключения между окнами программ.
Если вы хотите, чтобы ваш сервис возвращал данные контрагента при простом вводе адреса в браузере, необходимо реализовать поддержку метода GET. Передать параметр ИНН в данном случае можно двумя основными способами.
Вариант А. Использование параметров запроса (Query Parameters)
В этом случае адрес в строке браузера будет выглядеть следующим образом: http://localhost/http/hs/ServIIS/getdata?inn=7701234567. Проанализируем код обработки такого GET-запроса в модуле HTTP-сервиса 1С:
Функция getdata(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
// Получаем параметры из строки запроса URL
ИНН = Запрос.ПараметрыЗапроса.Получить("inn");
Если ИНН = Неопределено Или ПустаяСтрока(ИНН) Тогда
Ответ.КодСостояния = 400; // Bad Request
СтруктураОшибки = Новый Структура("error, text", Истина, "Не передан обязательный параметр 'inn'");
Ответ.УстановитьТелоИзСтроки(СформироватьJSON(СтруктураОшибки));
Возврат Ответ;
КонецЕсли;
СтруктураОтвета = Новый Структура("result, data");
СтруктураОшибки = Новый Структура("error, text", Ложь, "");
Попытка
ПараметрыПоиска = Новый Структура("inn", ИНН);
ДанныеКонтрагента = ПолучитьДанныеКонтрагентаПоИНН(ПараметрыПоиска);
СтруктураОтвета.data = ДанныеКонтрагента;
Исключение
СтруктураОшибки.error = Истина;
СтруктураОшибки.text = ОписаниеОшибки();
КонецПопытки;
СтруктураОтвета.result = СтруктураОшибки;
ТекстОтвета = СформироватьJSON(СтруктураОтвета);
Ответ.УстановитьТелоИзСтроки(ТекстОтвета, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);
Возврат Ответ;
КонецФункции
Вариант Б. Использование шаблонов путей URL (URL Templates)
Мы можем спроектировать более изящную структуру адреса (так называемый REST-style), где ИНН является частью самого пути: http://localhost/http/hs/ServIIS/getdata/7701234567. Для этого в свойствах шаблона URL в конфигураторе 1С необходимо указать следующий шаблон пути: /getdata/{inn}.
В коде обработчика 1С получение параметра изменится. Вместо коллекции параметров запроса мы будем использовать коллекцию параметров шаблона:
// Извлечение параметра из пути шаблона URL
ИНН = Запрос.ПараметрыШаблона.Получить("inn");
Этот вариант невероятно удобен для ручной проверки работоспособности сервисов непосредственно из адресной строки любого браузера или мобильного устройства.
Для того чтобы при отправке запроса из внешних систем (Postman, браузер, curl) управление передавалось в Конфигуратор и срабатывали точки останова, необходимо правильно выполнить системные настройки отладки. Разберем этот процесс по шагам.
1C:Enterprise 8.3 Server Agent в пути запуска (параметр ImagePath) добавьте в конец строки параметры -debug -http. После этого перезапустите службу сервера 1С.default.vrd. Откройте его текстовым редактором и убедитесь, что в теге <debug> разрешена отладка и указан верный адрес локального сервера отладки. Пример корректной строки:
<debug enable="true" protocol="http" url="http://localhost:1561" />
После редактирования файла default.vrd обязательно выполните перезапуск веб-сервера (IIS или Apache).
Рассмотрим профессиональный подход к проектированию HTTP-сервисов, предложенный опытными разработчиками. Писать тяжелую бизнес-логику (запросы к БД, создание документов, обработку алгоритмов заполнения) непосредственно в модуле самого HTTP-сервиса — крайне плохая практика.
Модуль HTTP-сервиса должен выполнять роль исключительно «Транспортного контроллера». Его задачи:
HTTPСервисОтвет.Давайте посмотрим, как красиво выглядит код контроллера при использовании такого подхода:
Функция getdatapost(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
Попытка
// Извлекаем текстовые данные из тела запроса
ТестЗапросаJSON = Запрос.ПолучитьТелоКакСтроку();
// Вся бизнес-логика выполняется в серверном общем модуле
РезультатСтруктура = ИнтеграцияКонтрагентыСервер.ВыполнитьПоискПоЗапросу(ТестЗапросаJSON);
ТекстОтвета = ИнтеграцияКонтрагентыСервер.СериализоватьДанныеВJSON(РезультатСтруктура);
Ответ.УстановитьТелоИзСтроки(ТекстОтвета, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);
Исключение
Ответ.КодСостояния = 500; // Internal Server Error
СтруктураОшибки = Новый Структура("error, text", Истина, ОписаниеОшибки());
Ответ.УстановитьТелоИзСтроки(ИнтеграцияКонтрагентыСервер.СериализоватьДанныеВJSON(СтруктураОшибки));
КонецПопытки;
Возврат Ответ;
КонецФункции
В чем преимущество такого архитектурного разделения? Во-первых, вы можете полноценно отлаживать всю логику поиска контрагентов, расчетов или проведения документов без необходимости постоянно дергать веб-сервер внешними запросами. Вы можете просто создать тестовую внешнюю обработку, которая вызывает метод ИнтеграцияКонтрагентыСервер.ВыполнитьПоискПоЗапросу(), передавая туда подготовленные тестовые данные в режиме реального времени. Во-вторых, этот подход защищает вас от долгих таймаутов веб-сервера при пошаговой отладке кода.