HTTP-сервисы

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

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

По сравнению с имеющимися в платформе SOAP web-сервисами, HTTP-сервисы имеют ряд преимуществ:

  • Простота программирования клиента таких сервисов;
  • Потенциально меньший объем передаваемых данных;
  • Потенциально меньшая вычислительная нагрузка;
  • HTTP-сервисы ориентированы на «ресурсы», в то время как SOAP сервисы ориентированы на «действия».

Первые три фактора особенно важны для приложений, работающих на мобильных устройствах.

Можно использовать HTTP-сервисы как «легкие» RPC-сервисы, не требующие сложной подготовки XML-пакетов. Методы могут идентифицироваться в URL, а параметры могут передаваться в опциях запроса, или в его теле. В последнем случае такие сервисы уже вплотную приближаются как SOAP, проигрывая ему в четкости спецификации, но выигрывая в гибкости.

По своему «конструктивному исполнению» HTTP-сервисы очень напоминают web-сервисы, имеющиеся в платформе. Точно так же есть специальный объект конфигурации HTTP сервис. Такие объекты добавляются в ветку Общие — HTTP-сервисы:

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

Шаблон задаёт путь, по которому может происходить обращение к HTTP-сервису. В шаблоне можно использовать определённый набор символов, в том числе параметризованные сегменты вида {какой-то текст}.

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

При обращении к такому HTTP-сервису платформа сначала попытается сопоставить URL, по которому произошло обращение, с одним из имеющихся шаблонов и методов. Если сопоставить не удалось, то платформа выдаст код ответа 404 Not Found. Если подходящий метод будет найден, то платформа начнёт выполнение его обработчика, передав в него все имеющиеся в запросе данные в виде объекта встроенного языка HТТРСервисЗапрос:

Из этого объекта можно легко получить, например, параметры, содержащиеся в исходном URL, и использовать их для извлечения из базы нужных данных.

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

Ответ сервиса формируется специальным объектом встроенного языка HТТРСервисОтвет, в тело которого можно поместить подготовленные данные.

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

Технологии интеграции 1С:Предприятия 8.3

Авторы: Е.Ю. Хрусталева

1С — WEB и HTTP сервисы, отличия и сходства, практика

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

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

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

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

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

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

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

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

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

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

 

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

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

  • Обмен с внешними системами (сайты, магазины, мобильные приложения),
  • Обмен данными между базами 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 сервисов, контроль данных у нас не производится.

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

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

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

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

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

 

В чем разница между веб-службой и службой HTTP?

спросил

Изменено 4 года, 3 месяца назад

Просмотрено 12 тысяч раз

В чем разница между веб-службой и службой HTTP? Я использовал службу HTTP с API REST. Но не в состоянии понять, что мы используем ключевое слово webservice и в чем разница между ними. Может ли кто-нибудь помочь мне лучше понять эти вещи.

  • веб-службы
  • http

Веб-служба конкретно относится к реализации SOAP, а HTTP просто относится к любой службе, использующей протокол HTTP, наиболее популярными из которых являются REST и SOAP.

Разница заключается в «полезной нагрузке» тела и некоторых других заголовках. Оба начинаются со стандартного формата HTTP:

 ACTION PATH VERSION.
Заголовок: Значение <повторять по мере необходимости>
<тело>

Отсюда они различаются по способу использования. REST обычно использует JSON, тогда как SOAP использует XML с определенными обязательными форматами.

SOAP более требователен к пропускной способности, чем JSON, но, как правило, лучше поддерживается в старом программном обеспечении. Существует формат WSDL, который указывает, как должны формироваться сообщения SOAP, что приводит к быстрому времени разработки (но, возможно, JSON в большинстве случаев так же быстр).

Обычно вы выбираете протокол в зависимости от ваших потребностей, обычно определяемых форматом, который поддерживает ваш язык программирования, и функциями, к которым вам нужен доступ из службы (SOAP и REST не всегда могут предлагать одни и те же вызовы API). Используйте REST, когда никакие другие факторы не диктуют выбора, и оставьте SOAP (веб-сервисы), если вам нужно его использовать.

4

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie

.

Приложения служб портала | georgia.gov

Билеты облачной поддержки

Интернет-запрос дилера

Приложение, приносящее доход, для предоставления услуг поиска Автомобильные дилеры изучают историю VIN. Использует внешний веб-сервисы для интеграции данных.

https://services.georgia.gov/gta/dii/

Код DHS COS

Электронные отчеты DPHL

ТОЛЬКО РАЗМЕЩЕННОЕ РЕШЕНИЕ —

Эта система позволяет лицам, уполномоченным Грузией Доступ Департамента общественного здравоохранения (DCH) для отчетности и цели лечения.

https://ereports.ga.gov/

Поиск уголовника в Джорджии

Приложение, приносящее доход, для предоставления услуг поиска для «RAP SHEET DATA» информации, предоставленной заказчиком. Предлагается в качестве платежного приложения для кредитной карты а также услуга учетной записи GPS.

Использует внешние веб-сервисы для интеграции данных.

https://services.georgia.gov/gta/gafs/

Коды проекта мейнфрейма GTA (MPC)

Билеты в службу поддержки GTA

Общее место для подачи запросов в службу поддержки, связанной с SharePoint, службами разработки приложений, службами обмена данными, Mobius View и управлением объектами в GTA.

https://services.georgia.gov/gta/zoho/

Лицензия соответствует

Приложение, приносящее доход, которое предоставляет услугу проверить данные водительских прав. Использует внешние веб-сервисы для интеграция данных.

https://services.georgia.gov/gta/ltnm/

Администратор ODI

Утилиты ODI (ODI – Innovations) включают следующее: функции для сотрудников ODI:

  1. Отслеживание транзакций клиентов (сотрудники ODI)
  2. Подготовка отчетов (персонал ODI)
  3. Управление транзакциями VMS

https://services. georgia.gov/gta/odi-admin/

ODI – Инновации

Структура приложения ODI – Innovations (ODI) включает в себя следующий:

  1. Записи о транспортных средствах — доступ к маркировке и названию транспортного средства информация через БЕСПЛАТНО (DOR)
  2. Корпорации (SOS)
    • Массовые корпорации Закупки данных

https://services.georgia.gov/gta/odi-innovations/

ОСТ АРИС

Управление государственного казначея по запросу о выделении Интранет-система (АРИС) позволяет госорганам получать выделяемые государственные средства либо в виде наличных денег, либо за подконтрольные фонды. Казначейство передает запросы на контролируемые средства непосредственно агентство фонда. Процесс сбора доходов позволяет агентства сообщать о сборе средств, таких как Государственный доход налог, который должен передаваться в казну, а не использоваться коллекторское агентство. Использует внешний интерфейс для предоставления данных в ДОР.

No related posts.