Что такое API / Хабр

Содержание

• Что такое API
  
  • API — набор функций
  • Как составляется набор функций
  • При чем тут слово «интерфейс»
• Как вызывается API
  
  • Вызов API напрямую
  • Косвенный вызов API
• Что значит «Тестирование API»
• Резюме

Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!

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

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

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

Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

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

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

Что такое 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. Им не нужна графика, только контракт.

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

Напрямую:

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

Косвенно:

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

Вызов API напрямую

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, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.

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

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

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

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

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

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

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

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

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

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

Когда говорят про API с тестировщиком, обсуждают два варианта:

• автотесты на уровне API (умение автоматизировать)
• интеграцию между двумя разными системами (обычно SOAP или REST, то есть работу в SOAP Ui или Postman).

Если вы хотите отработать второй вариант и поучиться отправлять запросики — используйте бесплатную систему Users! И мои обучающие видосики, например, «Как отправить REST-запрос за 5 минут».

Что такое API? Простое объяснение для начинающих

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

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

Всемирная паутина и удалённые серверы

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

При введении в адресную строку браузера www.facebook.com на удалённый сервер Facebook отправляется соответствующий запрос. Как только браузер получает ответ, то интерпретирует код и отображает страницу.

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

Jobs-бот найдет работу: подключайте бота в Telegram и получайте подходящие предложения

API как способ обслуживания клиентов

Многие компании предлагают API как готовый продукт. Например, Weather Underground продаёт доступ к своему API для получения метеорологических данных.

Сценарий использования: на сайте небольшой компании есть форма для записи клиентов на приём. Компания хочет встроить в него Google Календарь, чтобы дать клиентам возможность автоматически создавать событие и вносить детали о предстоящей встрече.

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

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

Регистрируйтесь на Currency.com и инвестируйте в токенизированные акции, крипту, сырье.

Чем API Google Календаря отличается от API любого другого удалённого сервера в сети?

Технически, разница в формате запроса и ответа. Чтобы сгенерировать полную веб-страницу, браузер ожидает ответ на языке разметки HTML, в то время как API Google Календаря вернёт просто данные в формате вроде JSON.

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

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

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

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

Таким образом, когда компания предлагает своим пользователям API, это просто означает, что она создала ряд специальных URL, которые в качестве ответа возвращают только данные.

Такие запросы часто можно отправлять через браузер. Так как передача данных по протоколу HTTP происходит в текстовом виде, браузер всегда сможет отобразить ответ. Например, через браузер можно напрямую обратиться к API GitHub (https://api. github.com/users/petrgazarov), причём без маркера доступа, и получить вот такой ответ в формате JSON:

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

Онлайн-курсы, чтобы разобраться с API

Developing APIs with Google Cloud’s Apigee API Platform

Exploring GraphQL: A Query Language for APIs

The React Developer Course with Hooks, Context API and Redux

Rest API Automation With Rest Assured

Bubble — новый гид по цифровому миру: как войти в айти и хакнуть свою жизнь

Ещё несколько примеров API

Слово «application» (прикладной, приложение) может применяться в разных значениях. В контексте API оно подразумевает:

• фрагмент программного обеспечения с определённой функцией,
• сервер целиком, приложение целиком или же просто отдельную часть приложения.

Любой фрагмент ПО, который можно чётко выделить из окружения, может заменять букву «А» в англоязычной аббревиатуре, и тоже может иметь некоторого рода API. Например, при внедрении в код разработчиком сторонней библиотеки, она становится частью всего приложения. Будучи самостоятельным фрагментом ПО, библиотека будет иметь некий API, который позволит ей взаимодействовать с остальным кодом приложения.

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

Для углубления в тему мы собрали список онлайн-курсов по API.

Что такое программный интерфейс приложений (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 в приложении для совместных поездок (райдшеринга)
• Создание виртуальных собеседников в службе обмена сообщениями
• Встраивание видеоклипов с YouTube на веб-странице
• Автоматизация рабочих процессов в программных инструментах для B2B-сектора

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

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

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

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

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

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

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

В некоторых случаях 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)

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

Автор: IBM Cloud Education

19 августа 2020 г.

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

Управляйте своими API с помощью IBM →

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

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

Как работает API

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

Вот как работает API:

1. Клиентское приложение инициирует вызов API для получения информации, также известный как запрос . Этот запрос обрабатывается из приложения на веб-сервер с помощью универсального идентификатора ресурса (URI) API и включает глагол запроса, заголовки и иногда тело запроса.

2. После получения действительного запроса API выполняет вызов внешней программы или веб-сервера.

3. Сервер отправляет ответ     в API с запрошенной информацией.

4. API передает данные  первоначальному запрашивающему приложению.

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

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

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

Зачем нам нужны API

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

• Улучшение совместной работы:  В среднем предприятие использует почти 1200 облачных приложений (ссылка находится за пределами IBM), многие из которых отключены. API-интерфейсы обеспечивают интеграцию, так что эти платформы и приложения могут беспрепятственно взаимодействовать друг с другом. Благодаря этой интеграции компании могут автоматизировать рабочие процессы и улучшить совместную работу на рабочем месте. Без API-интерфейсов многим предприятиям будет не хватать возможности подключения, и они будут страдать от информационных разрозненных хранилищ, которые снижают производительность и производительность.

• Простая инновация:  API обеспечивают гибкость, позволяя компаниям устанавливать связи с новыми деловыми партнерами, предлагать новые услуги на существующем рынке и, в конечном итоге, получать доступ к новым рынкам, которые могут приносить огромную прибыль и стимулировать цифровую трансформацию. Например, компания Stripe начиналась как API всего с семи строк кода. С тех пор компания установила партнерские отношения со многими крупнейшими предприятиями в мире, диверсифицировала свою деятельность, предлагая кредиты и корпоративные карты, и недавно была оценена в 36 миллиардов долларов США (ссылка находится за пределами IBM).

• Монетизация данных:  Многие компании предпочитают предлагать API бесплатно, по крайней мере на начальном этапе, чтобы они могли создать аудиторию разработчиков вокруг своего бренда и наладить отношения с потенциальными деловыми партнерами. Однако если API предоставляет доступ к ценным цифровым активам, вы можете монетизировать его, продавая доступ (это называется экономикой API). Когда AccuWeather (ссылка находится за пределами IBM) запустила портал самообслуживания для разработчиков, чтобы продавать широкий спектр пакетов API, потребовалось всего 10 месяцев, чтобы привлечь 24 000 разработчиков, продав 11 000 ключей API и создав в процессе процветающее сообщество.

• Дополнительная защита:  Как отмечалось выше, API создают дополнительный уровень защиты между вашими данными и сервером. Разработчики могут дополнительно усилить безопасность API, используя токены аутентификации, подписи и шифрование Transport Layer Security (TLS); путем внедрения шлюзов API для управления и аутентификации трафика; и практикуя эффективное управление API.

Общие примеры API

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

• Универсальные входы:  Популярным примером API является функция, которая позволяет людям входить на веб-сайты, используя свои данные для входа в Facebook, Twitter или Google профиль. Эта удобная функция позволяет любому веб-сайту использовать API одного из наиболее популярных сервисов для быстрой аутентификации пользователя, экономя время и усилия, связанные с настройкой нового профиля для каждой службы веб-сайта или нового членства.

• Сторонняя обработка платежей: Например, теперь вездесущая функция «Оплатить через PayPal», которую вы видите на веб-сайтах электронной коммерции, работает через API. Это позволяет людям оплачивать товары в Интернете, не раскрывая конфиденциальные данные и не предоставляя доступ посторонним лицам.

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

• Карты Google: Одним из наиболее распространенных примеров хорошего API является сервис Google Карт. В дополнение к основным API-интерфейсам, которые отображают статические или интерактивные карты, приложение использует другие API-интерфейсы и функции для предоставления пользователям направлений или достопримечательностей. Благодаря геолокации и нескольким уровням данных вы можете обмениваться данными с API Карт при построении маршрутов путешествий или отслеживании объектов в пути, таких как транспортное средство для доставки.

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

Типы API

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

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

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

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

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

(Примечание: все веб-API являются удаленными API — API, которые вызывают функции или работают с данными или ресурсами, которые находятся на компьютере, отличном от компьютера, отправляющего запрос.)

Типы протоколов API

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

• SOAP  (Простой протокол доступа к объектам) – это протокол API, построенный на основе XML, который позволяет пользователям отправлять и получать данные через SMTP и HTTP. API-интерфейсы SOAP упрощают обмен информацией между приложениями или программными компонентами, которые работают в разных средах или написаны на разных языках.

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

• JSON-RPC  – это протокол, похожий на XML-RPC, поскольку оба они представляют собой удаленные вызовы процедур (RPC), но в этом протоколе для передачи данных используется JSON вместо формата XML. Оба протокола просты. Хотя вызовы могут содержать несколько параметров, они ожидают только один результат.

• REST  (Representational State Transfer) – это набор принципов архитектуры веб-API, что означает отсутствие официальных стандартов (в отличие от протоколов). Чтобы быть REST API (также известным как RESTful API), интерфейс должен соответствовать определенным архитектурным ограничениям. Можно создавать RESTful API с протоколами SOAP, но эти два стандарта обычно рассматриваются как конкурирующие спецификации.

API, веб-сервисы и микросервисы

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

Традиционно API относился к интерфейсу, подключенному к приложению, которое могло быть создано с помощью любого из низкоуровневых языков программирования, таких как Javascript. Современный API соответствует принципам REST и формату JSON и, как правило, создается для HTTP, в результате чего интерфейсы, удобные для разработчиков, легко доступны и понятны приложениям, написанным на Java, Ruby, Python и многих других языках.

При использовании API существует два распространенных архитектурных подхода — сервис-ориентированная архитектура (SOA) и архитектура микросервисов.

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

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

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

Подробнее о взаимосвязи этих архитектурных подходов см. в статье «SOA и микросервисы: в чем разница?»

API и облачная архитектура

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

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

и API IBM Cloud

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

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

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

Сделайте следующий шаг:

• Ознакомьтесь с IBM API Connect, безопасным, интуитивно понятным решением для проектирования и управления API, которое помогает последовательно создавать API, управлять ими, обеспечивать их безопасность, социализировать и монетизировать. API Connect позволяет вам и вашим клиентам запускать цифровые приложения и стимулировать инновации в режиме реального времени. IBM названа лидером Forrester Wave™: Решения для управления API, третий квартал 2022 г. — читайте в отчете.

• Ознакомьтесь с решениями IBM Cloud Automation, включая решения для автоматизации ИТ, которые снижают затраты на облако и инфраструктуру на 30 % и ускоряют среднее время восстановления на 50 %, решения для автоматизации бизнеса, которые автоматизируют рабочие процессы и беспрепятственно интегрируют бизнес-системы, а также интеграционные решения, ускоряющие разработку до до 55%.

• Узнайте об IBM Cloud Pak® for Integration — программном решении для интеграции на основе ИИ, которое применяет замкнутый цикл автоматизации ИИ для поддержки различных стилей интеграции.

Начните работу с учетной записью IBM Cloud уже сегодня.

Рекомендуемые продукты

• API-подключение IBM
• IBM Cloud Pak для интеграции
• Подключить приложение

Что такое API? (Интерфейс прикладного программирования)

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

Что такое API? Наконец, узнайте сами в этом полезном видео от MuleSoft, экспертов по API.

Что такое пример API?

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

Чтобы лучше объяснить это, давайте возьмем знакомый пример.

Представьте, что вы сидите за столиком в ресторане с выбором блюд на выбор. Кухня – это часть «системы», которая будет готовить ваш заказ. Чего не хватает, так это важной связи, чтобы передать ваш заказ на кухню и доставить еду обратно к вашему столу. Вот тут-то и появляется официант или API. Официант — это мессенджер, или API, который принимает ваш запрос или заказ и сообщает кухне — системе — что делать. Затем официант возвращает вам ответ; в данном случае это еда.

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

Однако что, если вы не используете веб-сайт авиакомпании — канал, который имеет прямой доступ к информации? Что делать, если вы пользуетесь туристической онлайн-службой, такой как Kayak или Expedia, которая собирает информацию из нескольких баз данных авиакомпаний?

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

API также обеспечивает уровень безопасности

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

API-интерфейсы стали настолько ценными, что составляют большую часть доходов многих компаний. Крупные компании, такие как Google, eBay, Salesforce. com, Amazon и Expedia, — это лишь некоторые из компаний, которые зарабатывают на своих API. «Экономика API» относится к этому рынку API.

Современный API

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

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

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

Чтобы узнать больше об API и о том, как разработать отличный API, загрузите электронную книгу Undisturbed REST: A Guide to Designing the Perfect API.

+

Вы были перенаправлены

Вы были перенаправлены на эту страницу, так как MuleSoft приобрела Servicetrace. Кликните сюда, чтобы узнать больше.

+

Cette Page Est Dishonible En Français

Voir en Français

+

Diese Seite Gibt es Auch Auf Deutsch

Zur Deutschen Version

+ 9003

Zur Deutschen Version

+ 9003

Zur Deutschen Version

00 +

Zur Deutschen Version

00 +

Zur Deutschen Version

00 + 9003

ZUR DUTSCHEN.

+

Essa página está disponível em Português

Veja-a em português

+

この は 日本 語 で も ご 利用 いただけ いただけ ます

日本 で 見る

Что такое API?

Введите ключевые слова

Свяжитесь с нами

Select a language

• 简体中文
• English
• Français
• Deutsch
• Italiano
• 日本語
• 한국어
• Português
• Español

Добро пожаловать,

Войдите в свою учетную запись Red Hat

Войдите в систему

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника и настройкам, а также к следующим услугам в зависимости от вашего статуса клиента:

Зарегистрируйтесь сейчас

Еще не зарегистрированы? Вот несколько причин, по которым вы должны это сделать:

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

Редактировать свой профиль и предпочтения

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника, предпочтениям и другим услугам в зависимости от вашего статуса клиента.

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

Выход из системы

Логин аккаунта

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

API-интерфейсы

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

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

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

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

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

В качестве альтернативы распространитель книг может предоставить API для проверки наличия товаров на складе. У этого подхода есть несколько преимуществ:

• Предоставление клиентам доступа к данным через API помогает им собирать информацию о своих запасах в одном месте.

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

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

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

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

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

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

Предоставление ваших API партнерам или общественности может:

• Создать новые каналы дохода или расширить существующие.

• Расширьте охват вашего бренда.

• Содействие открытым инновациям или повышению эффективности за счет внешних разработок и сотрудничества.

Звучит здорово, правда? Но как API могут делать все это?

Вернемся к примеру с компанией по распространению книг.

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

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

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

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

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

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

Веб-API обычно используют HTTP для сообщений запросов и предоставляют определение структуры ответных сообщений. Эти ответные сообщения обычно имеют форму файла XML или JSON. И XML, и JSON являются предпочтительными форматами, поскольку они представляют данные таким образом, чтобы другим приложениям было легко манипулировать ими.

По мере распространения веб-API была разработана спецификация протокола, помогающая стандартизировать обмен информацией: простой протокол доступа к объектам, более известный как SOAP. API-интерфейсы, разработанные с использованием SOAP, используют XML для своего формата сообщений и получают запросы через HTTP или SMTP. SOAP упрощает обмен информацией между приложениями, работающими в разных средах или написанными на разных языках.

Еще одна спецификация — передача репрезентативного состояния (REST). Веб-API, которые придерживаются архитектурных ограничений REST, называются RESTful API. REST принципиально отличается от SOAP: SOAP — это протокол, тогда как REST — это архитектурный стиль. Это означает, что официального стандарта для веб-API RESTful не существует. Как определено в диссертации Роя Филдинга «Архитектурные стили и проектирование сетевых архитектур программного обеспечения», API-интерфейсы являются RESTful, если они соответствуют 6 основным ограничениям RESTful-системы:

• Архитектура клиент-сервер : Архитектура REST состоит из клиентов, серверов и ресурсов и обрабатывает запросы через HTTP.

• Отсутствие состояния : Между запросами на сервере не сохраняется клиентское содержимое. Вместо этого информация о состоянии сеанса хранится у клиента.

• Возможность кэширования : Кэширование может устранить необходимость в некоторых взаимодействиях клиент-сервер.

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

• Код по запросу (необязательно) : Серверы могут расширять функциональные возможности клиента путем передачи исполняемого кода.

• Единый интерфейс : Это ограничение является ключевым для разработки RESTful API и включает 4 аспекта:

  • Идентификация ресурсов в запросах : Ресурсы идентифицируются в запросах и отделены от представлений, возвращаемых клиенту.

  • Управление ресурсами через представления : Клиенты получают файлы, представляющие ресурсы. Эти представления должны содержать достаточно информации, чтобы их можно было модифицировать или удалить.

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

  • Гипермедиа как механизм состояния приложения : После доступа к ресурсу клиент REST должен иметь возможность обнаруживать через гиперссылки все другие доступные действия.

Этих ограничений может показаться много, но они намного проще, чем предписанный протокол. По этой причине API RESTful становятся более распространенными, чем SOAP.

В последние годы спецификация OpenAPI стала общим стандартом для определения REST API. OpenAPI предоставляет разработчикам независимый от языка способ создания интерфейсов REST API, чтобы пользователи могли понимать их с минимальными догадками.

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

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

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

Архитектуры микросервисов аналогичны шаблонам SOA тем, что в них используются специализированные, слабо связанные сервисы. Но они идут еще дальше в разрушении традиционной архитектуры. Службы в архитектуре микрослужб используют общую структуру обмена сообщениями, такую ​​как RESTful API. Они используют RESTful API для связи друг с другом без сложных транзакций преобразования данных или дополнительных уровней интеграции. Использование RESTful API позволяет и даже поощряет более быструю доставку новых функций и обновлений. Каждая услуга дискретна. Одна служба может быть заменена, улучшена или удалена без ущерба для любой другой службы в архитектуре. Эта облегченная архитектура помогает оптимизировать распределенные или облачные ресурсы и поддерживает динамическую масштабируемость для отдельных служб.

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

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