Что такое открытый api
Открытые API и новые финансовые приложения. Что и куда прикладывать?
Объясняет генеральный директор Ассоциации ФинТех (АФТ) Татьяна Жаркова.
Давайте разберемся, что такое открытые API, о которых все говорят, и почему их не надо бояться. Спойлер: вы уже ими пользуетесь.
Открытые API (англ. open APIs, openapplication programming interfaces) – это фактически общий интерфейс, а если проще – место встречи, язык и инструкция, с помощью которых «общаются» две и более программ. Эти программы могут находиться на разных компьютерах, на разных устройствах, в тысячах километров друг от друга. И, как правило, одна их них предоставляет сервис, а другая этот сервис использует, берет необходимые данные и функции.
Например, одна компания пишет программу для хранения данных, другая предоставляет товары или услуги, третья проводит денежные операции, а четвертая занимается доставкой оплаченных товаров. И все они, как части одного пазла, должны идеально подходить друг другу, обеспечивая бесшовный процесс выбора и оплаты товара для конечного потребителя.
И вы, даже если не задумываетесь об этом, наверняка уже пользуетесь открытыми API.
Например, если вы регистрируетесь на каком-то сайте с помощью учетной записи в Facebook, вы используете API этой социальной сети.
Когда вы скачиваете приложение в Google Play или AppStore, вы скачиваете программу, которую разработчик выложил в общий доступ с помощью API Google и Apple.
Когда вы общаетесь в чате с консультантом банка или агентом страховой компании, скорее всего, вы общаетесь с чат-ботом, который расположен на стороннем сервере и использует API кредитной организации или страховщика.
Или, когда вы едете на машине и используете тот или иной навигатор, экран показывает ваше местоположение на карте, прокладывает маршрут и показывает информацию о разных местах благодаря… верно, открытым API. Даже у космического агентства NASA есть открытые API, дающие всем желающим доступ к спутниковыми снимкам и данным о созвездиях.
Еще 10 лет назад сложно было представить, что нажатием одной кнопки вы вызовете такси, а водитель будет знать, где вас забрать и куда отвезти. При этом плата за поездку поступит на счет перевозчика без лишних действий с вашей стороны. А машина каршеринга сама идентифицирует вас по учетной записи и будет знать, какую музыку вам поставить. Сегодня все это стало обычным делом благодаря интеграции и взаимодействию программ, приложений и сервисов.
Сфер применения технологии открытых API множество – финансы, страхование, ритейл, мобильная разработка, корпоративные системы и т. д. Одно из самых перспективных направлений во всем мире – это банковские открытые API. Эта технология уже работает в Великобритании, Канаде, странах ЕС и др., а Россия в шаге от ее внедрения. В финансовом секторе такой инструмент позволит, например, создать приложение, в котором будут объединены все счета пользователя – вне зависимости от того, сколько у него карт и каких банков.
Представьте: в скором будущем всего одно приложение с вашего согласия сможет само проанализировать ежемесячные доходы, расходы, кредитную историю и подобрать для вас персональные предложения по ипотеке, а вам останется только выбрать наиболее подходящее. Тут же вы сможете застраховать сделку или недвижимость и даже, например, получить эксклюзивную скидку на мебель, услуги дизайнера или льготный кредит на бытовую технику. И все это – без запросов справок типа 2-НДФЛ, выписок со счетов и другой бумажной волокиты и хождения по офисам банков. При этом отдельные финансовые приложения не будут просить вас пройти дополнительную идентификацию – они сами «договорятся» между собой, кто чем займется, а вы получите персонализированные услуги, которые разработаны с учетом вашей финансовой ситуации, трат и привычек.
Для налаживания и развития такого многостороннего сотрудничества с другими компаниями банкам и дадут возможность открыть свои API – базы данных о системах, новых разработках и самом ценном – клиентах (но только после их согласия и в установленном ими объеме).
Конечно, доступ планируют открыть не для всех сторонних организаций, при этом будут четко определены условия. Подготовкой стандартов и механизмов внедрения открытых API занимается Ассоциация ФинТех (АФТ) совместно с Банком России и ключевыми игроками финансового рынка. Ассоциация проанализировала международный опыт и создала «Концепцию открытых API». Документ уже был направлен на рассмотрение в Банк России.
АФТ предлагает сразу «на входе» проверять всех потенциальных участников среды открытых API на уровень их информационной безопасности, чтобы данные были под защитой и впоследствии не «утекли», а также на юридическую и экономическую чистоту, чтобы компании несли ответственность за свою работу и были готовы покрыть экстренные расходы.
Предполагается, что каждый клиент банка сможет сам выбирать, каким компаниям предоставлять свои данные, какие именно и на какой срок (это может быть и единовременный доступ – на одну операцию), а также сможет закрыть доступ в любой момент. Несколько крупных банков – участников Ассоциации ФинТех уже участвуют в пилотировании проектов с применением открытых API в России. И в АФТ отмечают растущий интерес к этой технологии, ведь самим банкам она тоже очень выгодна: за счет сторонних сервисов они расширят каналы дистрибуции собственных услуг, а обмениваясь наработками с другими банками, получат возможность перенимать друг у друга опыт и повышать качество услуг. В итоге выиграют конечные потребители: будет расти количество финансовых сервисов и продуктов, возможности для управления денежными средствами, а вместе с этим – финансовая грамотность.
В чем польза формальных спецификаций вроде OpenAPI?
В этой статье хочу рассказать, что такое OpenAPI и зачем он может быть нужен.
Ваши покемоны
Ваше положение: у вас два разработчика. Один разрабатывает бекенд вашего продукта, а другой – фронтенд.
У вас есть идея для нового супер-классного приложения и вы хотите реализовать его как можно быстрее, поэтому вы призываете опытного архитектора чтобы он заранее спроектировал идеальный API, под который можно будет одновременно разрабатывать фронтенд и бекенд.
Архитектор разрабатывает идеальный API, описывает его в одном большом документе и выдает разработчикам.
Каждый разработчик берет документ, описывающий API, внимательно его читает, и реализует описанный API.
Пять раз отмерь, один раз отрежь
В конечном итоге мы хотим получить фронтенд и бекенд, каждый из которых будет реализовывать одни и те же запросы (фронтенд отправлять, а бекенд обрабатывать). В идеале, эти запросы должны еще и соответствовать тому, что описал архитектор (хотя это уже не так важно).
Давайте теперь посмотрим, что должно произойти чтобы запросы на фронтенде и бекенде совпадали:
Если хоть в одном из этих пунктов кто-то допустит ошибку, то весь ваш проект будет падать. И это с предположением, что архитектор не допускает ошибок (спойлер: таких нет).
Нужно отдельно отметить, что большая ноша ложится на человеческое понимание и человеческую коммуникацию технических деталей. Человеческое понимание в целом довольно трудно дебажить и тестировать.
Люди – самое слабое звено
Закономерным в сложившейся ситуации кажется желание минимизировать человеческий фактор в разработке API. Хочется не иметь человеческого фактора с того момента, как архитектор описал API в своем документе. (Вообще, хочется и от ошибок архитектора избавиться, но технологии до такого пока не дошли.)
Очевидно, что чтобы такое сделать, нужно чтобы выхлопом архитектора был не человеко-читаемый документ, а компьютеро-читаемый документ – своего рода формальная спецификация конкретного API. Если у нас будет такое описание API, мы можем как минимум попытаться возложить последующие шаги на автоматизацию.
Для каждого языка программирования при использовании какого-то конкретного фреймворка обычно не так много способов сделать «каноничную» реализацию какого-то HTTP API. Обычно в фреймворках не так много способов сделать запрос с JSON объектом в теле, и не так много способов считать целое число из пути запроса.
OpenAPI
Было бы здорово иметь возможность один раз описать свой HTTP API, и из этого описание получить совпадающие каркасы для реализации бекенда и фронтенда, которые, из-за отсутствия человека в цепочке, будут с большей вероятностью совпадать. (При условии, что генерация этих каркасов реализована без ошибок, но это, на самом деле, более простая задача.)
О, чудо! Такое уже придумали! И называется оно OpenAPI!
OpenAPI позволяет формально описывать HTTP API в виде YAML файлов. Довольно обширный пример можно посмотреть на editor.swagger.io. Там можно смотреть исходный YAML и человеко-читаемую HTML страничку одновременно.
Если изначальную спецификацию архитектор опишет в виде OpenAPI спецификации, то все взаимодействие между бекендом и фронтендом можно будет сгенерировать автоматически, и оно будет гарантированно совпадать. Таким образом мы вообще исключаем из цепочки человеческий фактор!
Больше чем просто кодогенерация
Кодогенерация – это лишь одно из применений OpenAPI. OpenAPI – открытый формат описания HTTP API, не завязанный на какую-то конкретную экосистему. Он позволяет обмениваться точным описанием API между системами, которые в иных условиях требовали бы ручной «синхронизации» API.
Есть большое количество инструментов, работающих на базе OpenAPI спецификаций. Хорошим ресурсом таких проектов является openapi.tools. Там представлены такие проекты как: GUI редакторы спецификаций, генераторы тестовых серверов по спецификациям, поиск уязвимостей по спецификации, и многое другое!
Используя OpenAPI можно не только повысить точность описания своих API, но и получить доступ к большому числу инструментов, которые помогут в разработке проекта.
Что такое API
Содержание
— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…
А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.
Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.
Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:
Что такое API
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:
API — набор функций
Когда вы покупаете машину, вы составляете договор, в котором прописываете все важные для вас пункты. Точно также и между программами должны составляться договоры. Они указывают, как к той или иной программе можно обращаться.
Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:
Тут вы можете мне сказать:
— Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!
Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция. Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое.
И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.
Как составляется набор функций
Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:
Можно не группировать вообще, а делать одно общее API.
Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.
Получается, что в нашей системе есть несколько разных API, на каждое из которых у нас написан контракт. В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут
И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает.
Получается, что разработчик придумывает, какое у него будет API. Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим.
При чем тут слово «интерфейс»
— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?
Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:
Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:
Как вызывается API
Вызвать апи можно как напрямую, так и косвенно.
Вызов API напрямую
1. Система вызывает функции внутри себя
Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!
Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)
Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…
2. Система вызывает метод другой системы
А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.
Одна система дергает через api какой-то метод другой системы. Она может попытаться получить данные из другой системы. Или наоборот, отправить данные в эту систему.
Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.
Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:
И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯
Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.
Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. Ну, может, парочка фильтров. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.
Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.
В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!
(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)
3. Человек вызывает метод
Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!
Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?
Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.
И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!
Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.
А еще в постмане можно сделать отдельную папку подготовки тестовой базы, напихать туда десяток запросов. И вот уже на любой базе за пару секунд вы получаете столько данных, сколько вручную вбивали бы часами!
Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.
4. Автотесты дергают методы
Есть типичная пирамида автоматизации:
Слово API как бы намекает на то, что будет использовано в тестах ツ
GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.
API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.
Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.
Косвенный вызов API
Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.
То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).
Но на самом деле под этим графическим пользовательским интерфейсом находится API. И когда пользователь нажимает на кнопочку, кнопочка вызывает функцию построения отчета.
А функция построения отчета уже может вызывать 10 разных других функций, если ей это необходимо.
И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!
Что значит «Тестирование API»
В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.
Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:
Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.
И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!
Резюме
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Оpen API: что это такое, как работает, и чем полезно бизнесу, финтех-стартапам и разработчикам
Что такое Open API
Опытные путешественники знают — в разных частях света розетки разные. Привычная для нас вилка не подойдёт к классической американской розетке. Вы хотите зарядить смартфон, и подобрали правильную вилку. Но это даже не полдела, а 1/3.
Разъём на выходе тоже должен совпадать с зарядным “гнездом” вашего телефона: быть плоским, круглым, mini-USB… Должна подходить и сама зарядка — выдавать нужное для мобильника напряжение. Смартфон сгорит, если пытаться зарядить его через преобразователь для чайника.
Понижающий преобразователь делает возможной зарядку смартфона, а одинаковые разъёмы обеспечивают взаимозаменяемость зарядок.
Это общий принцип работы протокола Open API (Application Programming Interface, открытый программный интерфейс приложения) Есть некая ценность, которой делится её автор (в нашем случае это электричество и условная розетка или электростанция). Есть пользователь, который посылает запрос и получает на него ответ (в нашем примере это смартфон). И есть промежуточное звено, которое делает возможным этот диалог на техническом языке (у нас — зарядка с определёнными разъёмами и преобразователь).
В компьютерном мире Open API — это “расшаривание” интерфейса и возможностей какого-либо продукта для сторонних разработчиков, партнёров, других игроков экосистемы. Они встраивают API в свои сервисы/приложения, делая их удобнее и функциональнее. Благодаря API мы с вами можем логиниться на сторонних сайтах через Facebook, вызывать такси по своей геолокации, платить парой кликов в интернет-магазинах. Сервисы интегрируются друг в друга и делают нашу жизнь удобнее.
API есть и в банках
Одна из важных областей использования технологии Open API — банковская. С её помощью банки и любые другие финансовые организации могут обмениваться данными (например, показывать на сайтах курсы валют, учитывая изменения в реальном времени) и предоставлять внешним площадкам готовые сервисы (например, для перевода денег между пользователями соцсетей).
В ЕС открытие банками Open API — требование “Второй платёжной директивы” (PSD2). К сентябрю 2019 года все финансовые учреждения Европы (не только банки) должны открыть свои API для сторонних разработчиков. Уже сделали это 23% игроков, ещё 51% планируют открыть интерфейсы приложений в течение года.
В Беларуси лёд также тронулся”. Профильные ведомства разрабатывают “”Дорожную карту разработки стандартов открытых банковских API” — она должна быть готова к 1 января 2020 года. Регулятор смотрит в этом направлении, но пока не делает его обязательным условием работы. Но самые прогрессивные банки и другие финансовые организации уже открывают API своих инструментов и сервисов.
Кому удобно, чтобы API банков были открытыми
Всем! В открытых интерфейсах банковских сервисов заинтересованы все: сами банки, их партнёры, финтех-стартапы, актуальные и потенциальные клиенты. Но не все финансовые учреждения открывают свои API. По разным причинам: одни банки не могут обеспечить сохранность персональных данных и защиту от мошенничества на сторонних площадках, другие — боятся конкуренции, их бизнес-модель не подразумевает взаимовыгодного партнёрства с третьими игроками.
Это их выбор, но по этому поводу ещё Iron Maiden пели: “Be quick or be dead”. Парадигма финансовых отношений медленно, но верно меняется во всём мире. Из консервативных держателей капитала банки превращаются в гибкие платформы для мгновенных платежей, переводов, инвестирования, страхования и пр. А те, которые не превращаются, уступают своё место на рынке более динамичным банкам и финтех-стартапам.
Чем Open API Альфа-Банка полезен бизнесу и его клиентам
28 июня Альфа-Банк открывает API для платежей в белорусских рублях. Теперь работать с инструментами банка станет ещё проще.
Юридические лица и ИП смогут…
Разработчики и финтех-стартапы смогут…