Интерфейс прикладной программы

Содержание
  1. API в современных приложениях
  2. Интернет и удаленные серверы
  3. Обслуживание клиентов с помощью API
  4. Где взять API?
  5. Виды API с точки зрения доступа
  6. Основные и наиболее популярные категории API
  7. Зачем создавать свой собственный API
  8. Сделал свой API, что дальше?
  9. Примеры использования API в различных приложениях
  10. Выводы
  11. Прикладной программный интерфейс
  12. API как оружие против конкурентов
  13. Прикладные программные интерфейсы и вы
  14. Что такое API
  15. API — набор функций
  16. Как составляется набор функций
  17. При чем тут слово «интерфейс»
  18. Как вызывается API
  19. 1. Система вызывает функции внутри себя
  20. 2. Система вызывает метод другой системы
  21. 3. Человек вызывает метод
  22. 4. Автотесты дергают методы
  23. Косвенный вызов API
  24. Что значит «Тестирование API»
  25. Резюме
  26. Что такое программный интерфейс приложений (API)
  27. Что такое программный интерфейс приложений (API)?
  28. Какую функцию выполняет API?
  29. Частные API
  30. Открытые API
  31. Примеры API
  32. Поиск, сбор и обмен данными
  33. Избавление от лишней работы
  34. Укрепление новаторства и сотрудничества
  35. REST или SOAP
  36. Ознакомьтесь с материалами по API

API в современных приложениях

Интерфейс прикладной программы

API или Application Programming Interface можно встретить в большинстве современных приложений и вебсайтов. Уже из названия понятно, что это интерфейс, предлагающий разработчикам готовые блоки для создания приложений. Когда ты пишешь приложение, ты обращаешься к такой «библиотеке» и берешь оттуда необходимые данные.

Пока что все выглядит просто и понятно. Надеемся, что так будет и в дальнейшем и ты быстро разберешься в теме и научиться применять API в своих приложениях. А если нет, то мы постараемся помочь тебе в понимании того, что такое Application Programming Interface и где он применяется.

Интернет и удаленные серверы

Что же такое Интернет? Это огромная сеть серверов, связанных между собой. На них и хранятся все сайты, которые ты можешь видеть, когда вводишь определенный УРЛ в строку браузера.

В принципе, сервером может стать и твой рабочий ноутбук. Он будет обслуживать твой сайт в сети, например.

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

Например, если ты введешь в строку браузера .com, то на удаленный сервер популярной соцсети будет отправлен запрос. После получения ответа, браузер отображает страницу. Всякий раз, когда ты заходишь на ту или иную страницу, ты уже взаимодействует с API.

Обслуживание клиентов с помощью API

В некоторых компаниях API идет как готовый продукт. Например, если это метеорологический сервис, покупая доступ к Application Programming interface, ты получаешь метеорологические данные.

А теперь посмотрим на то, как можно использовать API в своих собственных приложениях. Один из самых простых примеров – написание приложения, в котором пользователь сможет получать данные по погоде в своем городе. Для этого нам необходимо подготовить HTML макет и подключить соответствующий API, а затем, с помощью нескольких функций заставить это приложение работать.

Как пишется HTML код под приложение, мы здесь разбирать не будем, в этом нет смысла. Приложение писалось в библиотеке React, поэтому тем, кто с ней еще не знаком, некоторые моменты могут быть не совсем понятны, но мы поясним по ходу разъяснения.

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

Как это происходит? Пользователь твоего приложения хочет узнать, например, погоду в Москве. Для этого, он вбивает название города в поиск, который ты уже внедрил в приложение и получает результат.

В программе же этот результат достигается следующим образом. Функция getWeather отправляет запрос на сервер и получает ответ.

Дальше, в этой же функции мы спрашиваем, отвечает ли нам сервер. Если статус 404, значит мы не записываем никакие данные. А пользователь увидит undefined, ну или что-то другое, по твоему усмотрению.

Если же сервер отвечает, мы записываем ответы в state и, когда пользователь будет вводить, например, «Москва» в поиске приложения, у него отобразятся данные именно по Москве (в нашем случае это температура, название города, страны, погодные условия)

Это пример на React, но ты можешь сделать все это на чистом JS без проблем. Самое главное – понять, как все это работает. Как ты мог убедиться, принцип здесь тоже очень простой – отправка запроса на сервер, получение статуса сервера. Если он недоступен, ты в приложении сообщаешь об этом пользователю, например, в графе «Температура» будет написано «Неизвестно» или любой другой вариант.

Если же сервер доступен, пользователь увидит температуру в своем городе, название города, страну и погодные условия.

А вот как выглядит API Европейского центрального банка. Его можно использовать, например, при создании простейшего конвертера валют. Как видишь, здесь просто объект, в котором есть стандартный набор ключ:значение. Получая доступ к этому серверу, ты можешь сделать конвертер, который поможет твоим пользователям рассчитать курс интересующих их валют.

И это далеко не все. Сегодня очень многие приложения и вебсайты предлагают свои API разработчикам. Например, такой интерфейс есть на сайте GitHub, где в базе можно получить информацию по всем пользователям и определенным критериям.

API есть на криптовалютных биржах и с их помощью ты можешь создать свое приложение, которое будет «подтягивать» самые последние и актуальные котировки. Тот же CoinmarketCap работает по этому же принципу.

Через Application Programming Interface они получают данные с большинства крупных и не только бирж о токенах.

Где взять API?

Предположим, ты хочешь сделать свое приложение и тебе требуется API интерфейс для его реализации. Например, это будет тот же метеорологический софт. Один из способов – воспользоваться гуглом. Но есть один интересный сайт, где предложено множество API — https://rapidapi.com/. Здесь доступна обширная библиотека, которая постоянно пополняется.

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

После этого откроется страница, на которой будут представлены все API нужной категории.

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

Как видишь, все очень подробно. Очень многие API в свободном доступе, поэтому если ты сейчас изучаешь, например, JS или библиотеку типа React, ты можешь тренироваться с такими API в написании своих приложений для портфолио. Сервис требует регистрацию, пройти которую можно в том числе с помощью социальных сетей.

Виды API с точки зрения доступа

Существует два основных типа API – публичные и приватные. Первые встречаются в таких приложениях, как Slack или Shopify. Здесь разработчики делают упор на то, что интерфейсы могут использоваться на сторонних платформах. Подключение к такому API совершенно бесплатно, как и его использование.

Есть также приватные API. Они используются, в основном, внутри компаний. Если у фирмы множество внутренних продуктов, для взаимодействия между ними задействуется такой приватный интерфейс.

Основные и наиболее популярные категории API

Самыми часто используемыми интерфейсами этого типа являются:

  • API для работы с документами, загружаемыми в браузер. Например, это относиться к Document Object Model. Этот API позволяет работать с HTML разметкой и стилями CSS. То есть разработчик может менять вид страницы. Все, что появляется на странице достигается как раз благодаря DOM.
  • API, которые принимают данные с сервера. Ты уже немного знаком с этой технологией, так как мы ее показали примером выше. Когда мы создавали приложение для отображения погоды или конвертер валют, мы делали это именно с помощью данного типа API. Такой подход позволяет «оживить» вебсайт. Работать с серверами таким образом можно через Fetch API или XMLHttpRequest. Также есть термин AJAX, который описывает всю эту технологию.
  • API для работы с графикой. Они широко поддерживаются браузерами. Наиболее известными являются Canvas и WebGL. С помощью таких API ты сможешь программным путем менять данных о пикселях, которые содержатся в элементе html . То есть у тебя появляется возможность создания как двухмерных, так и трехмерных изображений с помощью такой технологии. Простой пример – создание какой-нибудь геометрической фигуры, например, треугольника с последующим импортом в canvas и применения различных фильтров. Конечно, эта технология позволяет создавать и более сложные элементы, в том числе трехмерные объекты. Эти API можно применять вместе с другими, например, с интерфейсами создания анимационных циклов. А здесь у тебя уже появляется возможность менять изображение на экране как играх или мультфильмах.
  • и видео API. Такие интерфейсы специально разработаны для того, чтобы у тебя была возможность поработать с мультимедиа в своем приложении или на сайте. К примеру, ты сможешь разработать свой пользовательский интерфейс для проигрывания аудио или видео записей. Ты сможешь добавлять на экран субтитры, записывать видео или аудио с камеры, а также применять различные видео и звуковые эффекты.
  • API различных устройств. В основном, это относится к считыванию данных с разных устройств для удобства работы с приложением. Например, есть специальное API, которое позволяет уточнить местоположения устройства. С его помощью ты сможешь написать свое приложение типа навигатора. Также есть API, которые позволяют уведомлять пользователя о появившихся обновлениях или API для включения вибрации смартфона.
  • API для хранения информации на стороне пользователя. Эти интерфейсы пользуются все большей популярностью, так как позволяют хранить данные на стороне клиента, даже если страница перезагружена. При этом, приложение может работать и тогда, когда нет подключения к сети Интернет. К таким интерфейсам можно отнести Web Storage API или IndexedDB API.

Зачем создавать свой собственный API

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

  • Мобильные приложения. Если ты заглянешь AppStore или Google Play Market, ты найдешь там множество софта, в котором используются API. То есть ты создал какую-то программу, сделал простой API и пользователи приложения будут получать информацию именно через этот интерфейс. Согласись, очень удобно и практично.
  • Open Source. Почему бы не использовать нужды твоей аудитории тебе же на благо? Сделал приложение? Создай к нему API, с помощью которого пользователи смогут создавать новые клиенты и сервисы.
  • Распределение фронтенд и бэкенд. Здесь речь идет о том, что сделать такое распределение можно, например, с помощью использования различных фреймворков для фронтенда.

Сделал свой API, что дальше?

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

Конечно, это может быть стандартный набор HTTP запросов для получения искомой информации. Но это неправильный подход. Наиболее подходящий вариант – создание собственной библиотеки, которая и будет работать с API и где ты опишешь все самые необходимые способы получения и отправки данных.

Первое, что сразу же приходит на ум –Octokit от GitHub. Это яркий пример таких библиотек. Что касается документации, в ней содержится вся необходимая информация для того, чтобы пользователь библиотеки знал, как отыскать требуемую информацию.

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

Примеры использования API в различных приложениях

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

В качестве примера, можно привести API Github. Здесь ты получишь всю информацию о пользователе, его аватарке, подписчиках, репозиториях и иные интересные данные. А если взять API , здесь можно получить информацию о пользователях, твитах, подписчиках и так далее. Такая информация может быть действительно крайне полезной при разработке сторонних приложений.

Выводы

Теперь ты знаешь, что такое Application Programming Interface. Ты можешь применять его в своих приложениях или создать приложение и разработать свой API для него, чтобы другие пользовались им.

На курсе Профессия: Продакт (с 0 до PRO) мы подробно разбираем кейсы крупных компаний, как Avito, Skyeng и другие. и делимся опытом создания и работы с профессиональной командой.

Также вы научитесь:

  • Изучите Hard Skills продакта (Приоритизация, Unit-экономика, CustDev, OKR и т.д.),
  • Прокачаете Soft Skills продакта,
  • Изучите лайфхаки быстрого прототипирования и проверки гипотез,
  • Ставить задачи, отслеживать их реализацию на уровне команды или удалённых подрядчиков.

Подробная программа курса и регистрация по ссылке ниже

Источник: https://zen.yandex.ru/media/id/5e9493565171d3396eba3545/api-v-sovremennyh-prilojeniiah-5f33c1727f79eb09ff917c72

Прикладной программный интерфейс

Интерфейс прикладной программы

05.03.2000 Дэвид Оринштейн, Дэвид Оренштейн

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

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

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

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

Предоставляя средства для запроса программных сервисов, API гарантирует доступ или возможность открытия приложения. По словам Джоша Уолкера, аналитика компании Forrester Research, «создание приложения без API напоминает строительство дома без дверей. Для любой вычислительной задачи прикладной программный интерфейс открывает окна и двери для обмена информацией».

Кроме того, прикладные программные интерфейсы обеспечивают взаимодействие приложений между собой.

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

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

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

По мнению Адама Браунштейна, аналитика компании Robert Frances Group, хотя API и обеспечивают быстрый и удобный способ доступа к приложению, они могут оказаться чересчур ограниченным средством для пользователей, которым требуются более широкие возможности, в частности для независимых производителей программного обеспечения.

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

Когда компания Novell в прошлом году сообщила о намерении предоставить широкой публике доступ к исходным текстам своего программного обеспечения Novell Directory Services (NDS), Крис Стоун, бывший в то время вице-президентом Novell, заявил, что большинство корпоративных разработчиков не хотят копаться в текстах свободно распространяемого обеспечения. На самом деле, по его словам, разработчики хотят получить дополнительные наборы API, с помощью которых они смогли бы работать быстрее. И до сих пор исходные тексты NDS так и не опубликованы.

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

Со временем вероятность того, что другому разработчику потребуется обратиться к сервисам этого приложения, только увеличивается.

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

Прикладные программные интерфейсы создавать несложно, но, как отметил Ларри Перлштейн, аналитик компании GartnerGroup, они могут оказаться трудными для изучения.

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

«API бесполезен, если на него нет документации», — подчеркнул Перлштейн, хотя некоторые производители оставляют свои API недокументированными.

API как оружие против конкурентов

Если компания хочет разочаровать разработчиков, она может хранить свои API в секрете или быстро их изменять. Многие критики корпорации Microsoft, в том числе государственные прокуроры и конкуренты, обвиняют компанию в том, что она не чурается подобной практики.

Эндрю Шульман описал несколько скрытых API операционной системы Windows в своей книге «Недокументированная Windows».

Сейчас он работает консультантом в компании Caldera, которая предъявила иск корпорации Microsoft, обвиняя ее в нарушении антимонопольного законодательства.

Теперь вместо сокрытия API, как пишет Шульман, «Windows имеет архитектуру типа ?кухонной раковины?, которая позволяет скрыть новые прикладные программные интерфейсы. Такое ?перемешивание? API — это попытка не допустить клонирования Windows».

Судья Томас Пенфилд Джексон привел аналогичные аргументы в своем выступлении 5 ноября в рамках слушаний по делу министерства юстиции против компании Microsoft. Он сказал, что «попытка клонировать API 32-разрядных Windows настолько дорогое и бесперспективное занятие, что появление конкурента для Windows становится практически невозможным».

Но Перлштейн отметил, что критикуя компанию за ее методы поддержки Windows API, конкуренты Microsoft дают волю своей зависти в ущерб справедливости.

Представитель Microsoft Джим Куллинан утверждает, что Microsoft постоянно совершенствует Windows, а также обновляет и добавляет прикладные программные интерфейсы, поскольку снижение скорости модернизации могло бы привести к невыполнению сроков выпуска.

Прикладные программные интерфейсы и вы

Прикладные программные интерфейсы (API) производят впечатление чего-то таинственного, а производители или разработчики не прочь поразмахивать ими как волшебными палочками, способными решить все проблемы.

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

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

Представьте, что у вас есть три соседа. Закрытый Зиновий, Открытый Оскар и API Анн. Каждый из них — это аналог приложения. Как и любому из соседей, вам иногда нужно у них что-нибудь позаимствовать, например газонокосилку. Это эквивалент интеграции приложений.

Закрытый Зиновий просто не оказывает вам никаких услуг. Он косит свою собственную траву за огородившим его дом высоким забором.

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

Такое приложение, как Закрытый Зиновий, не предоставляет ни исходных текстов, ни прикладного программного интерфейса.

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

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

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

API Анна позволит вам воспользоваться ее газонокосилкой, если вы правильно ее об этом попросите (вызвав прикладной программный интерфейс «дайкосилку» в тексте своего приложения).

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

Наиболее часто на предприятиях используются именно такие, закрытые, но имеющие API приложения, как Анна.

Прикладной программный интерфейс

Поделитесь материалом с коллегами и друзьями

Источник: https://www.osp.ru/cw/2000/09/3539

Что такое API

Интерфейс прикладной программы

Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API.

Что же это за зверь такой? Давайте разбираться! — А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал… А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой.

И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах. Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.

Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api.

И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

  • скучать в ожидании;
  • проверять логику работы по API

Конечно, я за второй вариант! Так что давайте разбираться, что же такое API. Можно посмотреть видео на , или прочитать дальше в виде статьи.

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:

  • мои обязанности — внести такую то сумму,
  • обязанность продавца — дать машину.

Перевести можно, да. Но никто так не делает ¯\_(ツ)_/¯ Все используют слово «контракт». Так принято. К тому же это слово входит в название стиля разработки:

  • Code first — сначала пишем код, потом по нему генерируем контракт
  • Contract first — сначала создаем контракт, потом по нему пишем или генерируем код (в этой статье я буду говорить именно об этом стиле)

Мы же не говорим «контракт на продажу машины»? Вот и разработчики не говорят «договор». Негласное соглашение.

API — набор функций

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

Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:

  • саму операцию, которую мы можем выполнить,
  • данные, которые поступают на вход,
  • данные, которые оказываются на выходе (контент данных или сообщение об ошибке).

Тут вы можете мне сказать: — Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!

Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция.

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

И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.

Как составляется набор функций

Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:

  • отдельно API для входа в систему, где будет регистрация и авторизация;
  • отдельно API для отчетности — отчет 1, отчет 2, отчет 3… отчет N. Для разных отчетов у нас разные формулы = разные функции. И все мы их собираем в один набор, api для отчетности.
  • отдельно API платежек — для работы с каждым банком своя функция.

Можно не группировать вообще, а делать одно общее API. Можно сделать одно общее API, а остальные «под заказ».

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

В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает. Получается, что разработчик придумывает, какое у него будет API.

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

При чем тут слово «интерфейс»

— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс? Да потому, что в программировании контракт — это и есть интерфейс.

В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:

  1. Инкапсуляция
  2. Наследование
  3. Полиморфизм

Инкапсуляция — это когда мы скрываем реализацию. Для пользователя все легко и понятно. Нажал на кнопочку — получил отчет.

А как это работает изнутри — ему все равно. Какая база данных скрыта под капотом? Oracle? MySQL? На каком языке программирования написана программа? Как именно организован код? Не суть. Программа предоставляет интерфейс, им он и пользуется.

Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:

  • что подать на вход;
  • что получается на выходе;
  • какие исключения нужно обработать.

Пользователи работают с GUI — graphical user interface. Программы работают с API — Application programming interface. Им не нужна графика, только контракт.

Как вызывается API

Вызвать апи можно как напрямую, так и косвенно. Напрямую:

  1. Система вызывает функции внутри себя
  2. Система вызывает метод другой системы
  3. Человек вызывает метод
  4. Автотесты дергают методы

Косвенно:

  1. Пользователь работает с GUI

1. Система вызывает функции внутри себя

Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API! Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик.

И он же его потребитель! А значит, проблемы с неактуальной документацией нет =) Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны.

Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…

2. Система вызывает метод другой системы

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

Или наоборот, отправить данные в эту систему. Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.

Я подключаю подсказки по API.

И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:

  • Он вводит букву на моем сайте
  • Мой сайт отправляет запрос в подсказки Дадаты по API
  • Дадата возвращает ответ
  • Мой сайт его обрабатывает и отображает результат пользователю

Вон сколько шагов получилось! И так на каждый введенный символ. Пользователь не видит этого взаимодействия, но оно есть. И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯ Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала. Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. Ну, может, парочка фильтров. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.

Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.

В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!

(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)

3. Человек вызывает метод

Причины разные:

  1. Для ускорения работы
  2. Для локализации бага (проблема где? На сервере или клиенте?)
  3. Для проверки логики без докруток фронта

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

Один раз сохранил — на любой базе применяешь, пусть даже она по 10 раз в день чистится. Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!

Конечно, это можно сделать в помощью специальных плагинов типа Form Filler.

Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?

Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.

И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!

Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.

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

Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.

4. Автотесты дергают методы

Есть типичная пирамида автоматизации:

  • GUI-тесты — честный тест, «как это делал бы пользователь».
  • API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
  • Unit-тесты — тесты на отдельную функцию

Слово API как бы намекает на то, что будет использовано в тестах ツ Допустим, у нас есть:

  • операция: загрузка отчета;
  • на входе: данные из ручных или автоматических корректировок или из каких-то других мест;
  • на выходе: отчет, построенный по неким правилам

Правила построения отчета:

  • Ячейка 1: Х — Y
  • Ячейка 2: Z * 6

GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.

API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.

Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.

Косвенный вызов API

Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно. То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает.

Пользователь работает через GUI (графический пользовательский интерфейс). Но на самом деле под этим графическим пользовательским интерфейсом находится API. И когда пользователь нажимает на кнопочку, кнопочка вызывает функцию построения отчета. А функция построения отчета уже может вызывать 10 разных других функций, если ей это необходимо.

И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!

Что значит «Тестирование API»

В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.

Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:

  • автотесты на уровне API
  • или интеграцию между двумя разными системами.

Интеграция — когда одна система общается с другой по какому-то протоколу передачи данных.

Это называется Remote API, то есть общение по сети, по некоему протоколу (HTTP, JMS и т.д.). В противовес ему есть еще Local API (он же «Shared memory API») — это то API, по которому программа общается сама с собой или общается с другой программой внутри одной виртуальной памяти.

Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.

И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!

Резюме

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

Контракт включает в себя:

  • саму операцию, которую мы можем выполнить,
  • данные, которые поступают на вход,
  • данные, которые оказываются на выходе (контент данных или сообщение об ошибке).
  • ».

Хабы:

  • Тестирование IT-систем
  • Тестирование веб-сервисов

Источник: https://habr.com/ru/post/464261/

Что такое программный интерфейс приложений (API)

Интерфейс прикладной программы

Пока вы это читаете, API-интерфейсы (программные интерфейсы приложений) связывают весь цифровой мир в единое целое.

Благодаря им на работе мы получаем возможность выполнять проекты быстрее и эффективнее, используя аналитику реального времени и высокоинтегрированные инструменты.

В сфере здравоохранения API объединяют клинические данные из различных источников и результаты исследований, что приводит к значительному ускорению разработки новых методов лечения и позволяет медучреждениям повышать качество медицинской помощи.

Возможно, вы удивитесь — как такие маленькие, но мощные API оказываются настолько полезными? Давайте ознакомимся с основными сведениями об API-интерфейсах и попытаемся понять, как же они связывают различные приложения.



Что такое программный интерфейс приложений (API)?

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

Какую функцию выполняет API?

Простой API. Источник: Experian

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

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

  • Внутренние/частные API
  • Внешние/открытые API

Частные API

Частные API доступны только разработчикам и пользователям из числа сотрудников организации. Такие API обычно связывают внутренние процессы для уменьшения разрозненности рабочих данных и оптимизации совместной работы.

Открытые API

Открытые API, в свою очередь, позволяют внешним разработчикам получать доступ к информации и интегрировать информацию, которая передается из одного программного инструмента в другой. Открытые или частные API экономят время разработчиков, позволяя им объединять платформы с имеющимися инструментами и устраняя необходимость в создании нового функционала с нуля.

Примеры API

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

  • Обмен информацией о рейсах между авиакомпаниями и туристическими сайтами
  • Использование Google Maps в приложении для совместных поездок (райдшеринга)
  • Создание виртуальных собеседников в службе обмена сообщениями
  • Встраивание видеоклипов с на веб-странице
  • Автоматизация рабочих процессов в программных инструментах для B2B-сектора

Поиск, сбор и обмен данными

Такие туристические сайты, как Kayak, используют API для сбора данных реального времени от авиакомпаний, отелей и экскурсионных бюро. Без оптимизированного доступа к подобной информации сотрудникам Kayak пришлось бы собирать эти данные вручную, или они просто не смогли бы предлагать такие выгодные туры.

В качестве других примеров использования API для обмена информацией в режиме реального времени можно назвать издание The New York Times, позволяющее анализировать свою базу данных, в которой хранятся тысячи статей, и сервис Spotify, который позволяет искать музыку различных стилей и направлений. Даже у агентства НАСА есть открытые API, открывающие доступ всем желающим к спутниковыми изображениями и информации о созвездиях.

Избавление от лишней работы

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

Например, API-интерфейс позволяет встраивать видеопроигрыватели на сайт, формировать отчеты и получать доступ к полезным ресурсам.  

Укрепление новаторства и сотрудничества

В некоторых случаях API оказываются на переднем крае инноваций в науке и технике.

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

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

[postbanner]

REST или SOAP

Когда вокруг так много разных приложений, вы можете задаться вопросом: а каким стандартам подчиняются API? Хотя в мире до сих пор не принят единый универсальный стандарт, есть несколько ведущих претендентов.

Эти стандарты, которые называются протоколы веб-сервисов, представляют собой наборы методов, определяющих способ передачи данных и доступа к API. Самые популярные протоколы, REST и SOAP, сейчас лидируют в этой гонке и используются подавляющим большинством открытых API-интерфейсов.

  • SOAP (Simple Object Access Protocol) до недавнего времени считался безусловным фаворитом у разработчиков API. Но сейчас 70% открытых API соответствуют протоколу REST. SOAP по-прежнему используется во многих крупных технических компаниях и обеспечивает поддержку устаревших систем, которые могут быть совместимы только с ним.
  • REST (Representational State Transfer) — это новый протокол веб-сервисов, позволяющий работать с большим количеством форматов данных. Кроме того, REST предпочтительнее для разработчиков, так как предлагает меньшее время загрузки и более высокую эффективность.

Ознакомьтесь с материалами по API

Вы готовы полностью раскрыть потенциал API в своей компании? Ознакомьтесь с этими материалами начального уровня. И заодно узнайте, как API Wrike могут преобразовать ваши методы работы.

  • Основные сведения об использовании API (TechnologyAdvice)
  • Восемнадцать полезных API для вашего следующего проекта (Medium)
  • Лучшая коллекция из 150 API для создания отличных программных продуктов (Medium)

Источник: https://www.wrike.com/ru/blog/chto-takoe-programmnyj-interfejs-prilozhenij-api/

Все термины
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: