WEB/HTTP сервисы. Базовые отличия и применение на практике

04.10.21

Интеграция - WEB-интеграция

Рассказываем о WEB и HTTP сервисах, их практическом применении, о шишках, которые мы набили, и о выводах, которые сделали. Спойлер: тех, кто дочитает статью до конца, ждет бонус от автора.

WEB и HTTP сервисы — две технологии, позволяющие получить доступ к 1С из внешней системы. Причем можно получить доступ как за файрволом, так и через прокси. В общем, практически из любой точки земного шара. 

С точки зрения 1С, это два объекта метаданных, которые позволяют нам выполнять эти операции. Реализовывается доступ по классической трехзвенной схеме: это СУБД, в качестве сервера выступают кластер серверов 1С и веб-серверы, и клиент, подключающийся к сервису.

 

 

Зачем это нужно?

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

  • Обмен с внешними системами (сайты, магазины, мобильные приложения),
  • Обмен данными между базами 1С (гетерогенные, РИБ),
  • Работа с внешним оборудованием (телефония, ТСД, весы),
  • Предоставление упрощенного интерфейса для пользователей,
  • Предоставление API для сторонних систем или партнеров.

В качестве примера можно привести сервис обмена данными, который в типовых конфигурациях в части передачи данных реализован также на WEB сервисах. По сравнению с традиционными COM-соединениями он намного более быстр, а информационные базы в этом случае могут базироваться на абсолютно разных платформах: как на версиях, так и на разных операционных системах. 

HTTP сервисы, поскольку они достаточно просты, могут выполняться на несложных и недорогих устройствах: таких как микрооборудование, телефония, терминалы сбора данных, электронные весы и так далее. Например, из 1С можно обратиться к IP-телефону, АТС или системе контроля доступа. В нашей практике был кейс, когда с телефонов Yealink вызывался сервис 1С, который записывал входящие звонки. Также это работало и в обратную сторону, и мы могли позвонить непосредственно с карточки клиента одним нажатием кнопки. Реализовывается это легко и быстро. 

Благодаря HTTP сервисам мы можем использовать мощь технологий HTML, PHP, JavaScript для того, чтобы предоставлять интерфейс для конечных пользователей. Причем интерфейс может быть быстрым и легким, для него не потребуется загружать всю платформу. Нам необходимо будет сделать всего лишь страничку, которая будет передавать данные на сервис HTTP. 

В нашей практике был случай, когда для заказчика нужно было  сформировать внешнюю печатную форму на основании обязательной анкеты, которую заполняли клиенты на специальном планшете. Для этого для планшета была сделана веб-страничка. И пока клиенты ждали своей очереди, они заполняли эту страничку, проставляя галки в нужных местах. При нажатии на кнопку «Отправить» данные отправлялись на сервис 1С, где уже всей мощью платформы формировался документ PDF с печатью и подписью, который затем распечатывался и прикреплялся к данным клиента. Все это было сделано за полтора дня, без изменений типовой конфигурации, в расширении.

Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис: 

 

 

Ниже скрин HTTP/WEB сервисов, которые используются у нас на текущем проекте. Обилие сервисов только подтверждает, что технология перспективная и очень интересная:

 

 

Ну, и самое последнее — это создание API для внешних систем, для сторонних партнеров. Дальше мы расскажем об этом подробнее. 

 

WEB и HTTP сервисы: сходства и различия

WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что: 

  • Предназначены для доступа к базе данных снаружи, 
  • Работают посредством веб-технологий, поверх протокола TCP,
  • Оба поддерживают технологии XML и JSON. 

Теперь расскажем о различиях. 

WEB технология — это сервисно-ориентированная технология, она по сути является удаленным вызовом процедур. Мы проектируем описание процедур, описание передаваемых параметров, и с помощью WEB сервисов мы эти процедуры можем вызывать. 1С со своей стороны также предоставляет технологию XDTO, которая позволяет валидировать входящие и исходящие данные, передаваемые в формате XML. 

HTTP сервисы же основаны практически на голом HTTP, и эта технология  ресурсно-ориентированная. Нет описания, нет проверки типов, нет проверки входящих и исходящих данных — есть только заголовки, параметры и тело запроса. И исторически используется формат данных JSON. 

 

 

Логично, что WEB-сервисы потенциально сложнее в реализации, потенциально используют больший объем передаваемых данных и дают потенциально большую вычислительную нагрузку. 

 

О форматах данных

Примерно так выглядит XML:

 

 

Это, кстати, хороший формат, позволяющий закодировать практически любые данные. А его мощь обеспечивает возможность создания шаблонов XML — XSD-схем, что описывают формат и допустимые типы данных.

Именно поэтому его используют различного рода госорганы. 

А так выглядит JSON — формат немного попроще:

 

Здесь есть основные типы данных: это объекты, формируемые фигурными скобками, массивы, формируемые квадратными скобками, и значение, которое формируется в виде текста. 

Данные для HTTP-сервиса передаются в виде запроса HTTP, схематично изображенного ниже:

 

 

Он состоит из строки запроса, из заголовка запроса, который представляет собой ключ и значение, также есть пустая строка и тело запроса в виде обычного текста. В теле запроса можно передавать любые данные, в том числе и двоичные, предварительно закодировав их в base64.

Так выглядит строка запроса в HTTP сервисе: 

 

 

Сервис HTTP ресурсно-ориентирован. Конечные точки, к которым мы можем обращаться, являются ресурсами: они представлены именами существительными. На схеме это элементы строки  orders и status, обозначающие соответственно ресурсы «Заказ» и «Статус заказа». Действия над ресурсами выполняются методами HTTP, базовыми из которых являются: get (получить ресурс), post (добавить ресурс), put (обновить ресурс), delete (удалить ресурс). Количество методов HTTP ограничено, действия над ресурсами тоже. Помимо указанных методов есть еще несколько дополнительных, но используются они значительно реже. 

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

 

Про проектирование

Теперь мы поделимся той болью, которую мы пережили при проектировании API с клиентами и партнерами. И теми шагами, которые необходимо предпринять, чтобы эту боль в будущем чуть-чуть уменьшить. 

При создании API предполагается, что пользоваться им  будем не  только мы, но и партнеры, и пользоваться достаточно долгое время. Здесь не обойтись без тщательного и взвешенного проектирования. Каждый момент должен быть учтен. 

 

 

Вспоминаем, что HTTP сервис — это у нас, в первую очередь, ресурсы. А ресурсы — это имена существительные: вот таких элементов, как /GetOrders или /orders/add, где в качестве ресурсов явно указываются глаголы действия, быть не должно. В качестве действий у нас должны выступать методы HTTP (get, post, delete). 

Правильное проектирование обычно идет по иерархии: коллекция, элемент, ресурс. И вот здесь мы специально отобразили один интересный момент, связанный с особенностями ресурсной иерархии. Например, к заказу у нас прикрепляются накладные. Есть заказ, есть накладные, которые выдаются по этому заказу (одна или несколько). К этим накладным мы можем дать доступ и как к отдельному ресурсу /invoices, и как к ресурсу в составе заказа — когда накладная сделана на основе заказа /orders/{id}/attachedInvoices. Эти сущности идентичны, по обоим ресурсам можно получить одни и те же объекты, но именуются они по-разному, для отражения особенностей их получения. Это еще одна из рекомендаций протокола HTTP. 

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

 

 

Благодаря этому мы понимаем, какое действие у нас происходит в случае применения каждого из методов HTTP к соответствующему ресурсу, а также можем легко расширять набор ресурсов и действий над ними. 

 

Про документацию

Если первый по важности пункт — это проектирование, второй — обязательно документация. HTTP протокол, HTTP сервисы не имеют описания, как это сделано в WEB сервисах. Поэтому документацию необходимо создавать, вести и обязательно поддерживать. Тем более, что ей пользуемся не только мы, но и партнеры. 

В самом начале мы «забивали» на документацию, а когда  партнеры спрашивали, каково предназначение того или иного метода, и что он в итоге принимает и возвращает — приходилось лезть в код. Теперь же мы просто говорим: посмотрите документацию, там все есть. 

Документацию мы рекомендуем вести в таком виде: 

  1. Адрес метода, предназначение, описание
  2. Входные и выходные параметры
  3. Описание структур данных в виде таблиц
  4. Описание обработки ошибок
  5. Примеры

Вот пример документации. Заголовок, ответ, пример, описание полей данных: 

 

Будь мужиком! Пиши логи!

На первых порах логи пишем всегда и везде. При получении запроса от нашего партнера — пишем в журнал все данные запроса, включая тело. При формировании ответа в критически важных участках кода примечания пишем в лог. При передаче запроса партнеру также пишем его в лог. Когда отправляем партнеру ответ, пишем в лог. Когда мы сами обращаемся к партнеру, пишем в лог. Ну, и при сбое, вы уже поняли, что мы делаем. 

 

Разделяй код и властвуй над ним 

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

На примере этого кода продемонстрировано использование указанных выше правил: 

 

 

В данном случае  метод выполняет получение прайса от партнера. При получении производится запись запроса в лог с указанием имени сервиса. Затем выполняется разбор запроса, подготовка данных и формирование ответа на запрос. 

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

После подготовки данных вызывается модуль бизнес-логики, где происходит обработка данных. Результат обработки возвращается в виде структуры, после чего происходит формирование тела ответа. 

Ну и тем, кто дочитал до конца, автор этой статьи предлагает свою демонстрационную базу: он выполнил все указанные принципы, перенес код из работающей системы и делится с вами безвозмездно (то есть даром). 

См. также

Модуль для обмена "1С:Предприятие 8. УАТ. ПРОФ" с FortMonitor

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ 3. Отчеты по данным загруженным в регистры сведений. Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен.

11856 руб.

25.05.2021    11756    9    4    

8

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Данная обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.

6000 руб.

02.02.2021    14456    34    43    

19

Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС

Обмен с ГосИС WEB-интеграция Платформа 1С v8.3 Управляемые формы 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия государственного учреждения 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Обработка является альтернативой механизму, разработанному фирмой 1С и заполняющему реквизиты контрагента по ИНН или наименованию. Не требуется действующей подписки ИТС. Вызывается как внешняя дополнительная обработка, т.е. используется, непосредственно, из карточки контрагента. Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС (egrul.nalog.ru) для БП 2.0, БП 3.0, БГУ 1.0, БГУ 2.0, УТ 10.3, УТ 11.x, КА 1.1, КА 2.x, УПП 1.x, ERP 2.x, УНФ 1.5, УНФ 1.6, УНФ 3.0, ДО 2.1

2400 руб.

28.04.2016    85185    142    211    

297

Прайс-лист с фотографиями, выгрузкой в Excel с подсчетом суммы заказа, загрузкой заказа в Управление торговлей 11 (Россия) и Управление торговлей для Беларуси 3

Прайсы Загрузка и выгрузка в Excel Оптовая торговля WEB-интеграция Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Прайс-лист для программы 1С: Управление торговлей 11 и Управление торговлей для Беларуси 3, позволяющий: 1) Формировать прайс-лист с фотографиями; 2) Сохранить прайс-лист в Excel с формулами, подсчитывающими количество и сумму заказа; 3) Передать сформированный прайс-лист по каналу ftp на сайт; 4) Сохранить прайс-лист в формате CSV; 5) Загрузить сделанный по прайс-листу заказ обратно в программу.

6000 руб.

04.09.2014    120830    44    105    

53

Sync1C: Синхронизация 1С и OpenCart

WEB-интеграция Оптовая торговля Розничная торговля Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Управленческий учет Платные (руб)

Внешняя обработка для обмена данными с интернет-магазином OpenCart. Позволяет быстро наполнить магазин товарами, затем обновлять цены и добавлять новые товары. Далее можно средствами OpenCart настраивать и дополнять карточки товаров как надо для магазина, при этом связь товаров с 1С не теряется.

3840 руб.

30.03.2018    41876    77    133    

81

Merlion Commander Версия 1.3.9.2 - июль 2022 г. (Интеграция с 1С: УT, редакция 11.4, 1С:Розница 2.3,1С:ERP Управление предприятием 2, УТ 10.3, редакция веб-сервиса MERLION API 3.0 от 18.08.2021)

Оптовая торговля Розничная торговля WEB-интеграция Платформа 1С v8.3 1С:Управление торговлей 11 Россия Платные (руб)

Расширении конфигурации "Управление торговлей, редакция 11" для работы с веб-сервисом Мерлион с помощью Merlion API. Расширение и набор подключаемых дополнительных обработок позволяет без изменения конфигурации получить возможность работы с API крупнейшего российского дистрибьютора http://merlion.com. Логика работы максимально приближена к работе веб-сервиса b2b. Вы сможете создать и исправить заказ, зарезервировать товар прямо из 1С, посмотреть актуальные остатки и цены, импортировать штрихкода EAN13 товаров, загружать заказ c автоматическим созданием номенклатуры в 1С и корректности создания. Можно выбирать характеристики по товарным группам и загружать товар с выбранными характеристиками, загружать изображения товара. Не требуется установки дополнительного ПО для работы с веб-сервисом. Кроссплатформенное решение для ОС Windows и Linux. Весь код модулей открыт и доступен для просмотра и внесения изменений.

8280 руб.

02.05.2017    37382    40    45    

47
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. KUAvanesov 04.10.21 18:11 Сейчас в теме
вот хочется чуть глубже. Например послушать про кейсы с идемпотентностью, или про то как открывать сессии и не заставлять пользователя постоянно проходить авторизацию. Чуть больше http и веба в статье про веб и http сервисы)
serega9507585993; dsdred; brr; +3 Ответить
10. Yashazz 4550 06.10.21 15:10 Сейчас в теме
(1) Такие статьи на ИС тоже уже были во множестве.
2. Steelvan 292 04.10.21 19:00 Сейчас в теме
В интернете полно всяких описанных случаев, каких хочешь.
Чтобы работник опознавался автоматически нужно на клиенте в обозревателе оставлять печеньки :)
kser87; axelerleo; +2 Ответить
3. DitriX 2081 04.10.21 19:03 Сейчас в теме
И опять никто не пишет, что SOAP - это овер http.
Т.е. в soap сервис можно так же http запросом передать тело, и фактически, оно ничем не будет отличаться от обычного http. Что очень часто и приходится делать, так как в SOAP 1С не хотят понимать заголовки, а рубят только тело.

А все остальное вкусовщина. Так что разница просто в документации и в ее способе передачи :)
Yashazz; dsdred; GATTUSO; Jeka44; Drivingblind; ardn; +6 Ответить
5. awk 740 04.10.21 23:21 Сейчас в теме
(3)Конечно не будет отличатся если смотреть очень издалека. Издалека и мальчик от девочки не отличается - человек же....
6. DitriX 2081 05.10.21 02:16 Сейчас в теме
(5) вы меня прям заинтриговали. Чем же принципиально отличаются эти технологии? Кроме того, что соап дает всдл, в котором описаны типы и функции,а для хттп - надо описывать отдельно это все, и обычно юзают фигнб разную типа свагера для этого.

А теперь мы возьмем реальные нагруженные проекты, где вам валются бинарники на вход (типо зипы, или base64bin), а не голый хмл.
Внимание, вопрос - чем хттп отличается от соапа в данной случае?
8. awk 740 05.10.21 09:42 Сейчас в теме
(6) Еще раз. Я не оспаривал мнение. Я говорил, что в первом приближении, все так и есть. Принципиально, технологии отличаются - подходом. REST - это технология состояния (расширение URL), а SOAP - это технология вызова процедур (расширение XML-RPC). И в обеих технологиях транспортом может быть http(s). А может, например, и не быть. SOAP может, например, работать и через TCP, без протокола прикладного уровня HTTP. А REST может быть построен и на FTP.

Как всегда дьявол кроется в деталях.
SagittariusA; Maxanamoon; Revachol; Yashazz; ubnkfl; John_d; CSiER; +7 Ответить
4. malikov_pro 1261 04.10.21 20:10 Сейчас в теме
Понятно желание автора опубликовать свой опыт, но даже на этом ресурсе прилично материалов с которыми можно состыковаться.
Оочень большие картинки, в которых немного толку.

Что хотели показать первой схемой? То что 1С есть другие веб серверы которые умеют работать с СУБД? Обычно такая же трехзвенка, и NGINX/Apache используют сокеты/сервисы а конкретном языке программирования.

"Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис: " - описание формата запроса который прилетает в сервис нет.

(3) Написать статью как получить wsdl от сервиса 1С через SoapUI и отправить его по postman?
"Работают посредством веб-технологий, поверх протокола TCP," - используют протокол HTTP, какие еще "веб-технологий" вы подразумевали?

Откройте для себя тег CODE редактора, в статье еще можно указать язык, для адекватной подсветки (касается и примеров кода на 1С)
<XM L>


"Вот пример документации. Заголовок, ответ, пример, описание полей данных:" - откройте для себя OpenAPI с переиспользованием в тестах postman например.

"Когда отправляем партнеру ответ, пишем в лог." - в каком формате ведете лог?

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


Оформите ссылку на код нормально, например на репо github.

Прошлись по верхам, получилась маркетинговая статья.
AdmKmpt; Irwin; kirillkr; Yashazz; litonchik; dreamadv; alexeyo51; igo1; CSiER; artbear; vano-ekt; rpgshnik; Drivingblind; ardn; +14 Ответить
11. Yashazz 4550 06.10.21 15:12 Сейчас в теме
(4) Дык это и есть сбор хайпа и плюсиков - позиционируется как "обзор" или "для новичков" в зависимости от характера упрёков авторам, а реальная полезность весьма низкая. Увы.
user1627011; Irwin; +2 Ответить
7. rpgshnik 3488 05.10.21 08:30 Сейчас в теме
Верстка треш, опять листинг не копируемый...
ardn; SuhoffGV; avbolshakov; dsdred; artbear; 1v7; +6 Ответить
9. FatPanzer 05.10.21 22:47 Сейчас в теме
Ну и где отличия, если все только про HTTP? А на заставке вообще нарисован гепард с черепахой (что как бы намекает на анализ скорости работы)... И где практика применения SOAP - ведт заголовок какбы предполагает...
AdmKmpt; Hans; malikov_pro; ardn; +4 Ответить
13. PLAstic 292 12.10.21 12:06 Сейчас в теме
Несколько моментов.

* Неопытность автора в данном вопросе следует из отсутствия предваряющего все "коллекции" указания версии. Т.е. грамотно д.б. так: GET/v213/orders/ и т.п.
* Из предыдущего следует, что обработка методов разных версий будет различаться.
* Обязательно должен существовать тестовый стенд новых версий, чтобы партнёры могли выполнять адаптацию и тестирование своих КИС на готовность к новой версии.
* Новые версии апи должны проходить как минимум одну неделю на тестовой среде для возможности партнёрам адаптировать свои системы.
* Должна существовать рассылка с добровольной подпиской на неё о новых версиях апи, чтобы партнёры могли поймать момент, когда вы инициируете процесс выкатки новой версии апи.
* Упоминаются входящие данные в типе структуры и вопрос валидации данных. Это взаимосвязанные вещи и решаются они использованием пакетов XDTO и объектной модели данных - не колхоз из структур и массивов, а объекты XDTO.
* Все объекты XDTO д.б. тщательным образом описаны в пакете. Где есть явные ограничения на значения, везде надо их указывать отдельно в типах XDTO, чтобы точнее валидировать входящие и исходящие данные.
* Почему-то автор избегал упоминания такого распространённого продукта как swagger. Он как раз предназначен для документирования апи и очень удобен для любых платформ партнёров.

И я бы обратил внимание, что GET-запросы уместны только в случае ограниченных данных. Если же вы хотите получить статус по списку заказов, то этот список может не влезть в 4К(зависит от веб-серверов) поля QUERY запроса. Очень хорошо, что вы понимаете изначальную суть GET и POST запросов и разницу между ними, но на текущий момент (кажется, в вики это описано) они утратили изначальный смысл. Обычно все используют запросы POST и информация из QUERY перемещается в BODY запроса в формате json. Там нет ограничений на объём. Попробуйте, это удобнее.

Приведу несколько важных фрагментов из Вики:
С помощью POST запросов можно было бы представлять новых клиентов, каждый из которых содержал бы имя, адрес, контактные данные и тому подобное. Разработчики сайтов отошли от этой концепции по двум причинам. Во-первых, нет никаких технических причин для URI текстуально описывать подчинённые веб-ресурсы, на которых будут сохранены данные, посланные методом POST. В самом деле, последняя часть URI более вероятно опишет страницу обработки веб-приложения и её технологию. Во-вторых, учитывая естественное ограничение большинства веб-браузеров использовать только методы GET или POST, разработчики понимали необходимость добавления дополнительных возможностей в метод POST, включая изменение существующих записей и их удаление.

Бывают случаи, когда HTTP GET менее подходит даже для получения данных. Примером является ситуация, когда большое количество данных должно быть записано в URL. Браузеры и веб-серверы могут иметь ограничения на длину URL, которые они обрабатывают без усечения или ошибки. URL-кодирование зарезервированных символов в адресе и строке запроса может значительно увеличить длину, в то время как HTTP-сервер Apache может обрабатывать до 4000 символов (8190 байт) в URL[1], Microsoft Internet Explorer ограничивает длину любого URL 2048 символами.

Равным образом, HTTP GET не должен использоваться для конфиденциальной информации, такой как имена пользователей и пароли, которые должны быть представлены вместе с другими данными для завершения запроса. Даже при использовании HTTPS, предотвращающим перехват данных при передаче, истории браузера и журналы веб-сервера, вероятно, содержат полные URL в виде открытого текста, которые могут быть найдены, если система будет взломана. В этих случаях используется HTTP POST.
Irwin; echo77; +2 Ответить
14. PLAstic 292 14.10.21 17:10 Сейчас в теме
16. Urmas 26.04.22 18:06 Сейчас в теме
(14)
OpenAPI

Не робит ссылка
15. pyrkin_vanya 480 02.03.22 09:52 Сейчас в теме
Добрый день. Подскажите, пожалуйста, как и где лучше составлять документацию?
17. PLAstic 292 05.07.22 10:18 Сейчас в теме
18. user803802 04.10.22 20:02 Сейчас в теме
Скачал вашу конфигурацию, опубликовал базу http://localhost/api - пытался в строке браузера сделать запрос:
http://localhost/api/hs/api/ping?api_key=56
Выдает страницу:
{
"code": 401,
"description": "Не передано значение параметра \"api_key\""
}
- комментариев в вашем коде конфигурации никаких.
Можете привести рабочий пример?
19. Lexaero 2 16.01.23 16:45 Сейчас в теме
(18)
Не передано значение параметра \"api_key\


Видимо ключик api_key не создан для контрагента в регистре сведений. Проверьте по коду - авторизацию
20. Antoska 17 18.01.23 17:45 Сейчас в теме
(19)
"Не передано значение параметра \"api_key\""


Буквально означает:
"Не передано значение параметра \"api_key\""
В конфигурации есть место с таким сообщением - модуль СервисыСлужебный функция АутентифицироватьПартнера()
В ней программа пытается получить токен из заголовков по имени api_key.
Прикрепленные файлы:
21. Lexaero 2 18.01.23 22:38 Сейчас в теме
(20) Да, все верно. В заголовках необходимо передавать авторизационный ключ api_key
22. olejnikov_m 47 18.02.23 12:21 Сейчас в теме
Здравствуйте коллеги! Из приложенного CF. Подскажите пожалуйста вот мы на вход в 1с передаем api_key а потом получаем из него хеш уже в самой 1с, это для чего? Чтобы определить кто с нами работает по Api? Но тогда зачем хеш хранить а не в явном виде? Просветите пожалуйста кто понимает, хочется разобраться...
23. Steelvan 292 07.03.23 12:43 Сейчас в теме
А мы делаем веб-приложения делового назначения на 1Сных http-сервисах.
Скорость разраобтки куда больше, чем на php и прочих языках.

Веб-формы получаются вполне на 1Сные похожи и людям привычные.
Например, https://infostart.ru/1c/articles/1818521/
Оставьте свое сообщение