Протокол интеграции что это
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО. Одни системы «из коробки» умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.
Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, в SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.
Самые известные способы реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.
SOAP (Simple Object Access Protocol) — данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns. Паттерны связывают HTTP методы с тем, что они делают.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос «Какой способ реализации использовать?» необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром. Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков «заготовок» — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.
API: что это такое в программировании и как работать с ним
Аббревиатура API встречается повсюду: в программных обеспечениях, интернет-протоколах, на сайтах. API используют многие сервисы и приложения. В статье объясним, зачем нужен API, расскажем о функциях и принципах его работы.
Что такое API и почему его называют интерфейсом
API (Application Programming Interface или программный интерфейс приложения) – это совокупность способов, протоколов, инструментов, с помощью которых различные программы обмениваются своими возможностями, данными, выполняют разные функции.
Зачем нужен API
API создан для удобства. Когда пользователь работает с планшетом или другим девайсом, ему не приходится вникать, как компьютер обрабатывает информацию: он просто нажимает на иконки в интерфейсе. Аналогичная ситуация с API. Благодаря программному интерфейсу разработчик может подключить свой продукт к другим системам для хранения файлов, отрисовки графики, воспроизведения видео или аудио. При этом ему не приходится писать собственный код или разбираться, как именно работает ОС. Такой алгоритм упрощает и ускоряет процессы.
Почему разработчики используют API
Перечислим основные причины интереса программистов к применению API:
Функции API
Некоторые компании предлагают API в качестве отдельного программного продукта. Допустим, вы хотите встроить интерактивные карты на сайт интернет-магазина, чтобы покупатель мог найти ближайший пункт выдачи товара, и выбираете API Яндекс.Карт. Разрабатывать собственный картографический сервис не придется. Сервис сайта отправит запрос к сервису Яндекса на поиск организаций на карте, а после получения ответа отобразит данные в браузере покупателя.
Типы API
Типы APIПо типу доступа программные интерфейсы API бывают:
WEB API, которые используют для создания HTTP-служб:
Использовалась, когда системы были связаны в локальных сетях. Принцип работы: вызов удаленных систем похож на вызов функций внутри программы. Яркие примеры таких систем – CORBA и DCOM.
Это протокол для обмена сообщениями в распределительной вычислительной среде. Помимо удаленного вызова процедур, SOAP способен отправлять и получать сообщения формата XML. Работает с протоколами прикладного уровня.
Это архитектура ПО для веб-служб. Обеспечивает работу с любыми форматами, будь то сайт, flash-программа, приложение другого формата и другие. Благодаря тому, что данные передаются без дополнительных слоев, REST использует меньше ресурсов, так как на каждую передачу данных требует меньше запросов.
Плюсы работы с API
Преимуществ работы с интерфейсом программирования много. Основные из них:
Как использовать API
Основная функция API – построение эффективной коммуникации между программами. Для разных целей интерфейс выполняет разные задачи.
В контексте интернета
Программный интерфейс позволяет быстро и просто получить доступ к источникам из другого программного приложения.
Например: зайти в личный кабинет интернет-магазина или профиль в социальной сети можно и через аккаунт на других веб-ресурсах. Это возможно благодаря API, установленным непосредственно в социальные сети. Код и API этих платформ дает клиентам доступ к другим приложениям.
В партнерском маркетинге
Работа с API в партнерском маркетинге облегчила труд программистов. Ранее они работали в SaaS – интеграции, которая предоставляла ПО как услугу посредством веб-интерфейса. Большую часть работы в сервисе приходилось выполнять вручную: это замедляло развитие партнерских программ и отражалось на стоимости работ. Теперь же программисты используют API как сравнительно быстрый и дешевый аналог.
Calltouch тоже может упростить работу и освободить время для решения более важных задач. Наши продукты помогают вашему бизнесу оптимизировать расходы на маркетинг.
Эффективный маркетинг с Calltouch
Особенности современного API
API сегодня — это товар. А его покупатели – разработчики ПО. Поэтому API постоянно дорабатывают, делают его доступным и удобным, выпускают регулярные обновления и занимаются поддержкой. Высокий спрос повышает качество продукта. Чтобы привлечь больше пользователей, разработчики создают новые идеи и дорабатывают ошибки, делают связь между приложениями надежнее и безопаснее.
Основные и наиболее популярные категории API
Чаще всего разработчики используют следующие типы интерфейсов:
Примеры API
Посмотрим, как разработчики интегрируют сайты и приложения с внешними сервисами, используя API, и как это влияет на функционал веб-продукта.
Google Календарь
Google Calendar API взаимодействует с приложениями, связанными с бронированием, организацией мероприятий и иными событиями, для которых нужно выделять время. Приложение синхронизирует данные из нескольких сервисов и позволяет просматривать, редактировать и удалять информацию о будущих событиях в одном месте.
Например, пользователь заказал билет на самолет или на концерт. Google Calendar API автоматически добавит дату и время полета или мероприятия в календарь.
Погодные приложения
Большинство погодных приложений пользуются API. Их разрабатывают сервисы, которые сотрудничают с метеостанциями напрямую.
Приложение делает запрос о погоде в конкретной геолокации. Программный интерфейс обрабатывает его и связывает с метеорологическим спутником, а после передает информацию пользователю.
Сервис по заказу авиабилетов
Билеты на самолет можно купить на сайте авиакомпании, но есть специальные сервисы, которые помогают найти подходящий рейс на указанные даты по выгодной цене. Агрегатор отбирает данные с разных сайтов и показывает ее в одном окне. В России по такому принципу работает известный агрегатор Aviasales.
Чтобы быстро собирать актуальную информацию, разработчики приложения для покупки билетов пользуются API сервисов авиакомпаний.
Умный сервис сквозной аналитики от Calltouch так же работает по умному принципу: система объединяет данные о разных маркетинговых мероприятиях компании и создает информативные и понятные отчеты. Закажите сквозную аналитику и сократите бюджет на бесполезную рекламу.
Сквозная аналитика
Кнопки авторизации
Навигация на сайтах и в приложениях
По аналогии с работой погодных приложений, другие сервисы тоже пользуются данными программных интерфейсов. Спутники предоставляют геоданные для тех или иных приложений. С ними работает API, проецируя на графический интерфейс карту. Эта карта используется не только в приложениях-навигаторах, но и в сервисах для вызова такси или заказа курьерской доставки.
Зачем создавать собственный API
Теперь обозначим частые ситуации, в которых удобно использовать API для собственных веб-продуктов:
Как вызывать API
Разработчики предоставляют пользователям подробное руководство по работе с интерфейсом. Обычно вызов происходит прямым и косвенным способами.
Вызов API напрямую
Это способ, при котором пользователь целенаправленно работает с API и ее функционалом.
Система вызывает функции внутри себя
Пользователь делает вызов из интерфейса. При этом составные части API связываются друг с другом на программном уровне. Допустим, первая функция интерфейса связана с удалением строки из таблицы. Она вызывает вторую для обновления данных.
Система вызывает метод другой системы
Этот способ мы уже описывали ранее. Используется, когда система хочет получить или отправить данные из совершенно другой ОС. Например, разработчик подключает к своему сайту сторонний сервис: сайт отправит запрос на удаленный ресурс через API и отобразит полученный ответ.
Вызов метода пользователем
Применяется тестировщиками, чтобы:
Можно вызывать метод без графического интерфейса вручную, если он содержит ошибки или пока не работает.
Автотесты вызывают методы
Автотест — это робот, который ищет ошибки в приложении, имитируя действия пользователей. В некоторых случаях удобно это делать не через GUI, а через API. Разработчик вносит данные на вход и проверяет их на выходе: так легче выявить и устранить баги.
Косвенный вызов
Каждый пользователь, открывая программу, работает с API. Например, нужно создать вкладку в браузере. Мы нажимаем кнопку и вызываем API, скрытый под удобным пользовательским интерфейсом. То есть, выполняя действие, мы отправляем команду множеству функций, но видим только результат — открытую вкладку.
Как тестировать API
Здесь нужно уточнение. Строго говоря, тестируется не сам программный интерфейс, а функционал сервиса с использованием API. Используя это выражение, программисты имеют в виду автотесты на уровне API. В отличие от тестирования GUI, здесь тестируется бизнес-логика и архитектура приложения.
Прежде чем приступать к работе, настраивают среду, в которой будет тестироваться интерфейс. Есть несколько видов тестирования:
После проведения работ, тестировщик анализирует результаты теста.
Заключение
API это необходимый элемент многих сайтов и приложений. Он помогает разработчикам создавать удобные сервисы в сжатые сроки, сохраняя ресурсы. Благодаря API для своих проектов можно использовать чужие веб-продукты, а можно создавать свои и делиться ими с другими. С развитием технологий применение программного интерфейса станет повсеместным.
Варианты протоколов для интеграции со сторонними системами в современных СКУД
Наиболее распространенным примером такой интеграции является организация взаимодействия между системой контроля доступа и системой видеонаблюдения. На практике интеграцию можно реализовать, например, и с помощью установки дополнительных реле либо использовать имеющиеся дополнительные входы/выходы в контроллерах и видеокамерах. Однако это дает очень ограниченные возможности. Основным способом, безусловно, является реализация программного взаимодействия между подсистемами. Производители СКУД стараются создавать различные средства, позволяющие программистам разрабатывать собственные приложения, удобные для использования конечными пользователями интегрированной системы. Но разнообразие выпускаемого оборудования очень большое, и на сегодня типовых решений по интеграции или стандартных протоколов организации подобного взаимодействия пока нет. Каждый спасается, как может. Данная статья посвящена обзору существующего положения на рынке и тем трендам, которые существуют.
Существуют два подхода для интеграции СКУД в состав системы безопасности. В первом случае реализуется алгоритм прямого управления непосредственно аппаратными средствами. Во втором организуется взаимодействие между программными средствами подсистем безопасности. Оба пути развиваются независимо, у обоих есть свои преимущества и недостатки.
Прямое управление аппаратными средствами
Первый подход реализуется тогда, когда интегратор хочет получить наиболее широкие возможности по управлению оборудованием и получению данных. Для реализации данного подхода необходимо организовать непосредственное управление «железом» по протоколам, предоставленным производителем СКУД. Сделать это возможно в случае, если производитель передал свой протокол разработчику программных средств на основании какого-либо договора, либо производитель сам позаботился и создал контроллер с универсальным интерфейсом. С помощью этой методики любой желающий, имеющий описание протокола и структур данных, может самостоятельно разработать программное обеспечение, позволяющее решать вопросы интеграции.
Но у данного подхода есть и недостатки. Прежде всего это необходимость постоянно следить за изменениями протоколов, хорошо понимать работу аппаратных средств, следить за расширением предоставляемых возможностей и т. п. То есть такая интеграция требует постоянных трудозатрат с чьей-либо стороны – либо производителя, либо разработчика программного обеспечения (ПО). Это не очень удобно, так как отнимает дополнительное время у программистов. Практически разработка не заканчивается никогда. Наш опыт подобных интеграций показал, что для поддержания эффективности интеграции производитель должен фактически вести список сделанных изменений и постоянно оповещать о них. Таких интеграций может быть несколько десятков, и требуется оповещать всех разработчиков ПО, следить за качеством выполненных доработок, проводить тестирование и т. д.
Если же производитель создал собственный контроллер с универсальным открытым протоколом (интерфейсом), то в случае выпуска нового исполнения контроллера либо расширения функций существующего должна быть соблюдена преемственность – старая версия прибора должна работать с новым протоколом и наоборот, что исключит постоянную доработку ПО сторонними производителями.
Взаимодействие программных модулей
Именно поэтому основным вариантом на сегодня является организация интегрированных решений на базе взаимодействия программных модулей. Данный вариант более универсален. Но здесь тоже нет одного решения, так как программные средства и требования клиентов постоянно растут и изменяются.
Взаимодействие с помощью SDK
Естественным развитием первого описанного подхода к интеграции стала разработка многочисленных SDK. SDK – комплект средств разработки, используемый разработчиками программного обеспечения для управления аппаратными средствами. В состав этого комплекта входит набор полезных утилит, исходные коды и библиотеки, предназначенные для создания приложений, тестирования программ и просто ускорения процесса разработки. Использование исходных кодов налагает ограничение на выбор языка программирования – интегратор должен либо использовать тот же язык программирования, что и создатель SDK, либо создать подключаемую библиотеку (DLL), реализующую методы SDK. При таком подходе повышаются и требования к квалификации разработчика-интегратора, и ответственность создателя SDK. Требуется практически постоянно создавать обновления, что достаточно трудоемко, поэтому не все производители оборудования и разработчики выбирают такой способ интеграции.
Взаимодействие через API
Следующий вариант программной интеграции – реализация производителем некоего набора программных запросов (методов или точек входа), позволяющих взаимодействовать с программными и аппаратными средствами в формализованном виде, – API (API, англ. application programming interface – интерфейс программирования приложений). Фактически это набор готовых процедур (библиотек, функций), предоставляемых для использования во внешних программных продуктах, легко подключаемых и используемых с любым современным языком программирования. API – универсальное средство, при его реализации сложные аспекты взаимодействия с оборудованием и протоколы обмена, структуры данных скрыты от интегратора и упрощены разработчиком API. Обмен информацией происходит посредством вызова неких функций, что позволяет организовать динамический обмен данными между приложениями. К сожалению, практика использования подобного рода интерфейсов показывает, что они не всегда могут быть корректно использованы из-за недостаточного понимания порядка работы интегрируемых систем и аппаратных средств со стороны разработчиков ПО. Из-за этого могут возникать непредсказуемые ошибки в работе ПО.
Взаимодействие через единую базу данных
Еще одним известным вариантом создания условий для интеграции является принцип взаимодействия через единую базу данных. В этом случае разрабатывается общая объектная модель – единый цифровой формат названий полей данных, записей таблиц и их взаимосвязей при организации базы данных интегрированной системы. Это позволяет записывать данные о работе системы в единую базу данных и выполнять их анализ. Запросы в эту базу создаются специально разработанными приложениями и разрабатываются одним разработчиком. Информация о конфигурации системы в целом и отдельных подсистем тоже хранится в централизованной базе данных. Недостатки у этого варианта аналогичны уже описанным в данной статье при рассмотрении первого подхода к интеграции.
Все вышеописанное не ново, и организация взаимодействия программных средств обычно базируется на технологии клиент – сервер. Суть этой технологии в том, что клиент может вызвать сервер, а обратный вызов невозможен. Данная технология повсеместно используется в процессах автоматизации чего-либо (бизнес-процессов, производства и т. п.). Она развивается много лет, и здесь имеются наработанные методики, являющиеся стандартом в сфере разработки программного обеспечения для систем безопасности. В то же время производители аппаратных средств ищут новые подходы и стараются предоставить такие средства для интеграции, которые были бы понятны широкому кругу программистов и не требовали бы глубокого понимания порядка их работы. Одним из них является организация взаимодействия с помощью несложных текстовых протоколов. Например, использование таких известных текстовых форматов, предназначенных для обмена данными, как XML-RPC, SOAP и JSON. Использование данных форматов удобно для большинства программистов, занимающихся разработкой программных приложений, поэтому написание новой программы для интеграции новых аппаратных средств не требует от них больших усилий и времени. В то же время они оптимальным образом подходят для реализации новых трендов рынка – web-сервисов, а также мобильных и web-приложений.
Поддержка web-сервисов
Относительно новым требованием рынка, предъявляемым к программному обеспечению для систем безопасности, в том числе и СКУД, стала поддержка web-сервисов. Эта задача заставила производителей подняться на новый уровень, позволяя обеспечивать взаимодействие со своими средствами в распределенных сетях. Использование старых подходов в этом случае затруднено из-за сложности описания путей поступления информации от сервера СКУД к клиенту. Этот процесс включает в себя несколько этапов: отправка запроса web-сервису, получение ответа, контроль формирования и получения запросов, а также многое другое. Одной из основных задач сервера в этой архитектуре является предоставление клиентам доступа к ресурсам (базе данных) по их идентификаторам. Уже существует большое количество наработанных методик и стандартов. Одним из них является стандарт SOAP, вторым – REST. Условно SOAP есть эволюция XML-формата, с натяжкой конечно.
SOAP – простой протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур, сейчас протокол используется для обмена произвольными сообщениями. Методы REST более просты, чем SOAP, и предназначены для построения распределенного приложения. В REST используются XML и JSON, при этом вызов удаленной процедуры представляет собой обычный HTTP-запрос, а необходимые данные передаются в качестве параметров запроса. REST и SOAP являются стандартами, на которых базируются технологии создания web-сервисов и широко используются при разработке приложений для средств автоматизации.
Неоднородность подходов и вариантов интеграции СКУД на рынке систем безопасности можно объяснить тем, что компании предлагают продукты, в которых реализуется только часть задач интеграции, никто пока не поставляет полностью оптимального решения. Связано это с тем, что для таких систем, как СКУД, не создано универсальных протоколов. Мешает этому большое количество разнообразных обрабатываемых данных. Попытки разработки таких протоколов, например ONVIF-C (основанный на SOAP), очень скромно описывают перечень передаваемых данных, поэтому их использование пока не оправданно, необходимо развивать его дальше. Другим предлагаемым вариантом является разработка производителями специализированных контроллеров-преобразователей со стандартизированным протоколом обмена типа «запрос – ответ».
Это предложение тоже находится на рассмотрении у производителей. Но надо учитывать, что, согласно прогнозам аналитиков, рынок услуг в области СКУД является очень перспективным и растущим сегментом рынка систем безопасности. Потребность в интеграционных решениях постоянно растет. По независимым оценкам, ожидается устойчивый рост поступлений от реализации данного вида программного обеспечения. Все это требует совместных усилий от производителей СКУД с целью создания универсальных методик, позволяющих широкому кругу программистов использовать выпускаемые аппаратные средства.