Этот краткий термин на слуху у всех, кто хоть как-то сталкивался с разработкой. Но далеко не все понимают, что именно он обозначает и зачем нужен. Разработчик Пётр Газаров рассказал об API простыми словами в своём блоге.
Аббревиатура API расшифровывается как «Application Programming Interface» (интерфейс программирования приложений, программный интерфейс приложения). Большинство крупных компаний на определённом этапе разрабатывают API для клиентов или для внутреннего использования. Чтобы понять, как и каким образом API применяется в разработке и бизнесе, сначала нужно разобраться, как устроена «всемирная паутина».
Всемирная паутина и удалённые серверы
WWW можно представить как огромную сеть связанных серверов, на которых и хранится каждая страница. Обычный ноутбук можно превратить в сервер, способный обслуживать целый сайт в сети, а локальные серверы разработчики используют для создания сайтов перед тем, как открыть их для широкого круга пользователей.
При введении в адресную строку браузера www.facebook.com на удалённый сервер Facebook отправляется соответствующий запрос. Как только браузер получает ответ, то интерпретирует код и отображает страницу.
Каждый раз, когда пользователь посещает какую-либо страницу в сети, он взаимодействует с API удалённого сервера. API — это составляющая часть сервера, которая получает запросы и отправляет ответы.
API как способ обслуживания клиентов
Многие компании предлагают API как готовый продукт. Например, Weather Underground продаёт доступ к своему API для получения метеорологических данных .
Сценарий использования: на сайте небольшой компании есть форма для записи клиентов на приём. Компания хочет встроить в него Google Календарь, чтобы дать клиентам возможность автоматически создавать событие и вносить детали о предстоящей встрече.
Применение API: цель — сервер сайта должен напрямую обращаться к серверу Google с запросом на создание события с указанными деталями, получать ответ Google, обрабатывать его, и передавать соответствующую информацию в браузер, например, сообщение с запросом на подтверждение пользователю.
В качестве альтернативы браузер может сделать запрос к API сервера Google, минуя сервер компании.
Чем 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
Слово «application» (прикладной, приложение) может применяться в разных значениях. В контексте API оно подразумевает:
- фрагмент программного обеспечения с определённой функцией,
- сервер целиком, приложение целиком или же просто отдельную часть приложения.
Любой фрагмент ПО, который можно чётко выделить из окружения, может заменять букву «А» в англоязычной аббревиатуре, и тоже может иметь некоторого рода API. Например, при внедрении в код разработчиком сторонней библиотеки, она становится частью всего приложения. Будучи самостоятельным фрагментом ПО, библиотека будет иметь некий API, который позволит ей взаимодействовать с остальным кодом приложения.
В объектно-ориентированном проектировании код представлен в виде совокупности объектов. В приложении таких объектов, взаимодействующих между собой, могут быть сотни. У каждого из них есть свой API — набор публичных свойств и методов для взаимодействия с другими объектами в приложении. Объекты могут также иметь частную , внутреннюю логику, которая скрыта от окружения и не является API.
Начнем с основ: что такое API? Аббревиатура расшифровывается как Application Programming Interface, или интерфейс для программирования приложений. Название, вроде бы, говорит само за себя, но лучше рассмотреть более детальное объяснение.
Как уже было сказано, API – это, в первую очередь, интерфейс. Интерфейс, который позволяет разработчикам использовать готовые блоки для построения приложения. В случае с разработкой мобильных приложений в роли API может выступать библиотека для работы с "умным домом" – все нюансы реализованы в библиотеке и вы лишь обращаетесь к этому API в своём коде.
В случае веб-приложений, API может отдавать данные в отличном от стандартного HTML формате, благодаря чему им удобно пользоваться при написании собственных приложений. Сторонние общедоступные API чаще всего отдают данные в одном из двух форматов: XML или JSON. На случай, если вы решили сделать API для своего приложения, запомните, что JSON намного более лаконичен и прост в чтении, чем XML, а сервисы, предоставляющие доступ к данным в XML-формате, постепенно отказываются от последнего.
API в веб-приложениях на примерах
Некое приложение – например, Github – имеет свой API, которым могут воспользоваться другие разработчики. То, как они будут пользоваться им зависит от возможностей, которые предоставляет API и от того, насколько хорошо работает фантазия у разработчиков. API Гитхаба позволяет, например, получать информацию о пользователе, его аватаре, читателях, репозиториях и множество других полезных и интересных сведений.
Подобным образом можно посылать запрос на любом языке, в том числе и на Ruby. Ответом на запрос будет примерно такая информация:
{ "login" : "Freika" , "id" : 3738638, "avatar_url" : "https://avatars.githubusercontent.com/u/3738638?v=3" , "gravatar_id" : "" , "url" : "https://api.github.com/users/Freika" , "html_url" : "https://github.com/Freika" , "followers_url" : "https://api.github.com/users/Freika/followers" , "following_url" : "https://api.github.com/users/Freika/following{/other_user}" , "gists_url" : "https://api.github.com/users/Freika/gists{/gist_id}" , "starred_url" : "https://api.github.com/users/Freika/starred{/owner}{/repo}" , "subscriptions_url" : "https://api.github.com/users/Freika/subscriptions" , "organizations_url" : "https://api.github.com/users/Freika/orgs" , "repos_url" : "https://api.github.com/users/Freika/repos" , "events_url" : "https://api.github.com/users/Freika/events{/privacy}" , "received_events_url" : "https://api.github.com/users/Freika/received_events" , "type" : "User" , "site_admin" : false , "name" : "Evgeniy" , "company" : "" , "blog" : "http://frey.su/" , "location" : "Barnaul" , "email" : "" , "hireable" : true , "bio" : null, "public_repos" : 39, "public_gists" : 13, "followers" : 15, "following" : 21, "created_at" : "2013-03-01T13:48:52Z" , "updated_at" : "2014-12-15T13:55:03Z" }
Как видно из блока выше, ответ содержит логин, аватар, ссылку на профиль на сайте и в API, статус пользователя, количество публичных репозиториев и прочую полезную и интересную информацию.
Одного API недостаточно
Создать полноценный API для своего приложения – лишь половина дела. Как вы предполагаете обращаться к API? Как к нему будут обращаться ваши пользователи?
Первое, что приходит в голову, это обычная серия HTTP-запросов с целью получения нужной информации, и это неправильный ответ. Самый очевидный способ в этом случае не является самым удобным и простым. Гораздо разумнее будет создать специальную библиотеку для работы с интерфейсом, в которой будут описаны все необходимые способы получения и отправки информации при помощи API.
Еще раз воспользуемся Github для приведения примера: для работы с АПИ этого прекрасного сервиса (а интерфейс у него предоставляет обширнейшие возможности) создано несколько библиотек на различных языках, например гем Octokit . В документации к таким библиотекам (и приведенному в качестве примера гему) любой заинтересованный разработчик сможет отыскать все необходимые способы получения информации от Гитхаба и отправки её обратно через API сервиса.
Таким образом, если вы создаете собственный API, подумайте, возможно стоит озаботиться созданием так же и библиотек для работы с ним на наиболее распространенных языках. И будьте готовы, что при определенном уровне востребованности вашего приложения кто-то другой может создать собственную библиотеку для работы с вашим API. Это нормально.
Полезные ссылки
В последующих статьях мы расскажем о том, как правильно создавать API, обеспечить его безопасность и ограничить доступ к части информации.
В этом сообщении я постарался собрать информацию, которая может пригодиться тестировщикам, желающим узнать, что такое API. Надеюсь что-то полезное для себя найдут и опытные в тестировании API люди. Ну или хотя бы помогут найти ошибки в моей статье:)
Что такое API
API (Application Programming Interface) - набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах (Wikipedia).
Своими словами, API предоставляет нам возможность использовать чужие наработки в своих целях. Впервые я столкнулся с API на примере Windows API. Это набор функций, которые может использовать любое приложение, запущенное на данной ОС. К примеру, оно может использовать стандартные функции для отрисовки интерфейса.
Современные API часто принимают форму веб-сервисов, которые предоставляют пользователям (как людям, так и другим веб-сервисам) какую-то информацию. Обычно процедура обмена информацией и формат передачи данных структурированы, чтобы обе стороны знали, как взаимодействовать между собой.
На сайте https://dev.hh.ru/ (а точнее, https://github.com/hhru/api/blob/master/docs/general.md) вы можете найти описание того, как клиенты и сервисы HeadHunter API взаимодействуют между собой. Например, цитата с сайта:
- Всё API работает по протоколу HTTPS.
- Авторизация осуществляется по протоколу OAuth2.
- Все данные доступны только в формате JSON.
- Базовый URL — https://api.hh.ru/
- Даты форматируются в соответствии с ISO 8601 : YYYY-MM-DDThh:mm:ss±hhmm
Форматы передачи данных
Существует множество форматов данных, с помощью которых пользователи взаимодействуют с API. Например, широко известный XML. Или JSON - легковесный и несложный формат, который выглядит как:
{ "id": "0001", "type": "donut", "name": "Cake", "image": { "url": "images/0001.jpg", "width": 200, "height": 200 } } По ссылкам ниже вы можете посмотреть ответы, приходящие от MediaWikiAPI , в разных форматах:
JSON:
https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=jsonfm
XML: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=xmlfm
PHP: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=php (осторожно, произойдет с
качивание
файла)
HTTP глаголы
Обычно при обращении к веб API используют ся запросы HTTP. Поэтому нужно хотя бы коротко сказать о стандартных методах, которые могут содержаться в HTTP запросе. Эти методы также называют HTTP глаголами:
- GET. Наверное, самый популярный тип запроса. Используется для получения или чтения данных.
- PUT. Обычно и спользуется для обновления ресурса.
- POST. Обычно используется для создания нового ресурса.
- DELETE. Удаляет данные.
- И другие
GET http://www.example.com/customers/12345
Если мы хотим обновить ресурс - мы можем послать PUT-запрос:
PUT http://www.example.com/customers/12345/orders/98765
Обычные GET запросы способен посылать веб-браузер. Для посылки других типов запросов могут потребоваться скриптовые языки или специальные инструменты (об этом будет ниже).
О HTTP методах можно подробнее почитать на W iki .
HTTP к оды ответов
Сервер может посылать разные коды в ответ на запросы пользователей. Это могут быть коды ошибок или просто коды, информирующие пользователей о состоянии сервера. Подробное описание можно найти, опять же, на вики .
Наиболее известные коды - 4xx (проблемы на стороне клиента) и 5xx
(проблемы на стороне сервера). О том, какие коды возвращать в той или иной ситуации, решают разработчики самих API. Например, API сайта Одноклассники возвращает
коды, описание которых можно найти на странице https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003 .
Кроме того, советую послушать песню Реквест-респонс - просто и понятно о кодах, возвращаемых в HTTP запросах (осторожно, репчик:)).
REST API
REST API - э то идеология построения API, которая расшифровывается как Representational State Transfer API. Она основывается на следующих принципах , сформулированных ее создателем, Роем Филдингом :
- Клиент-серверная архитектура
- Stateless сервер
- Кешируемость
- Многослойная структура
- Единый интерфейс
- Код по требованию
API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.
Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API - это множество «ручек», которые доступны пользователю данного ящика, которые он может вертеть и дёргать.
Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию - высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.
По такому принципу построены протоколы передачи данных по . Стандартный протокол Internet (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи пакетов бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему уровню.
Важно заметить, что понятие протокола близко по смыслу к понятию API. И то и другое является абстракцией функциональности, только в первом случае речь идёт о передаче данных, а во втором - о построении компьютерных приложений.
API библиотеки функций и классов включает в себя описание сигнатур и семантики функций .
Application Programming Interface (API) программный интерфейс взаимодействия между системами, позволяющий:
- Получать доступ к бизнес-сервисам предприятия
- Обмениваться информацией между системами и приложениями
- Упростить взаимодействие между компаниями, партнерами, разработчиками и клиентами
Open API стратегия
API стратегия включает в себя:
- Разработку бизнес-продуктов на основе существующих API
- Предоставление внутренних сервисов разработчикам
- Модели монетизации API для построения мультиканального взаимодействия и повышения прибыли
Реализация концепции Open API помогает трансформировать бизнес, встраивать его в гибкую проектную экосистему игроков рынка, создавать условия для постоянной генерации новых идей и формирования дополнительной ценности при управлении массивами корпоративных данных.
Рынок интеграционных решений развивается в контексте эволюции API - от EDI и SOAP до Web 2.0 , с которого началась эра публичных API. Число таких интерфейсов в ближайшие 3 года может вырасти более чем в 50 раза и достичь 1 миллиона. Это связано с мультиканальностью: каналы взаимодействия с клиентами должны меняться вместе с ними. Непрерывный рост количества потребителей и объема данных привел к появлению экономики API, помогающей на основе открытых интерфейсов создавать инновационные бизнес-модели использования корпоративных активов и сервисов.
Сигнатура функции
Сигнатура функции - часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функции в этих языках.
Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.
Например, в языке программирования Си++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет учаcтвовать и имя класса.
Также необходимо отметить, что в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый API обычно реализован с использованием API программных компонент более низкого уровня абстракции.
Например: для того, чтобы увидеть в браузере строчку «Hello, world!» достаточно лишь создать HTML -документ с минимальным заголовком, и простейшим телом, содержащим данную строку. Что произойдёт, когда браузер откроет этот документ ? Программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл, и разберётся в его устройстве, повызывает через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать выбранным шрифтом Hello, world!», при этих операциях библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы с запросами вида «а положи-ка мне в буфер видеокарты вот это».
При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML , а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные HTML-библиотеки, и, кроме того, всё это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.
Основными сложностями существующих многоуровневых систем API, таким образом, являются:
- Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
- Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.
Основные типы API
Внутренние API
- Доступ к API предоставляется только внутренним разработчикам
- Приложения нацелены на сотрудников предприятия
Бизнес-драйверы:
- Консистентность разработки
- Снижение затрат
- Повышение эффективности разработки
Партнерские API
- API доступны только ограниченному набору бизнес-партнеров
- Приложения предназначены для конечных потребителей и для бизнес-пользователей
Бизнес-драйверы:
- Автоматизация процесса разработки
- Развитие партнерских отношений
- Оптимизация процесса взаимодействия с партнерами
Публичные API
Доступ предоставляется любому внешнему разработчику Приложения нацелены на конечных пользователей
Бизнес-драйверы:
- Разработка новых сервисов
- Развитие экосистемы
- Мультиканальное взаимодействие
Наиболее известные API
API операционных систем
API графических интерфейсов
- Direct3D (часть DirectX)
- DirectDraw (часть DirectX)
Для того, чтобы облегчить труд своих коллег и обеспечить всем программам для Windows универсальный интерфейс, программисты Microsoft создали такую вещь, как API - "Application Programming Interface".
Это - набор функций и процедур, которые могут наиболее часто использоваться программами: отображение дерева каталогов, поиск файлов, отображение стандартного окна с кнопками закрытия, минимизации и развертывания на весь экран и многих других. В итоге разработчик, создающий программу для Windows, не должен продумывать и разрабатывать специальные подпрограммы для отображения окна программы, окна для выбора папки и остальных подобных элементарных операций, - ему достаточно просто вызвать из библиотек kernel32.dll или user32.dll, содержащих функции и процедуры API, нужную ему функцию, а она уже все сделает за него сама. Таких функций и процедур много - порядка 600.
В операционной системе MS-DOS такого понятия, как API, не было, - тот, кто брался писать программу для этой операционной системы, обязан был сам, от начала до конца, продумать и реализовать способы выдачи на экран изображения, получения данных от пользователя, путешествия по файловой системе, рисования графики, если таковая возможность была необходимой 2 . Это делало процесс разработки программ с удобным для пользователя интерфейсом весьма трудоемким процессом, зачастую затраты времени и сил на создание приемлемого графического интерфейса программы превосходили затраты на реализацию собственного алгоритма программы, ради которого она и создавалась. Недаром были очень распространены так называемые "консольные" приложения, то есть программы, работающие только из командной строки, без интерфейса, - ввод данных происходил в той же командной строке или производился из указанного в ней файла, а вывод результатов шел в простом текстовом режиме.
С появлением операционной системы Windows каторжный труд программистов по разработке внешнего вида программы и удобных способов ввода и вывода информации резко облегчился, - уже в Windows 3.0 использовались функции API. Теперь программист, если он, например, желал создать окно ввода текста или полосу прокрутки, должен был всего лишь написать вызов функции отображения такого окна с необходимыми ему параметрами, так же, как и любой другой функции языка, на котором он писал свою программу, а не вводить огромные обьемы кода ради создания программы, заново рисующей такое окно или полосу (сознавая при этом, что при разработке следующей программы, в которой тоже будут использоваться такие объекты, ему придется вновь разрабатывать такой код или пытаться частично использовать старый, приспосабливая его к нуждам этой новой программы). Поэтому появление API совершило революционный прорыв в технологии программирования, позволяя создавать нужные программы с привычным удобным интерфейсом гораздо быстрее, не заботясь о таких рутинных деталях, как программирование стандартных объектов интерфейса для ввода и вывода информации.
В языке Visual Basic for Applications (VBA) многие функции и процедуры API вызываются сами при выполнении программы интерпретатором, так что использовать их для отображения окон ввода и вывода текста, рисования на экране геометрических фигур и других простых действий совершенно нет необходимости, - их VBA вызывает по мере надобности, а программе на нем достаточно использовать соответствующие функции этого языка. Однако иногда возникает необходимость в некоторых действиях, для которых либо нет аналогов во встроенных функциях VBA, либо они работают нерационально или слишком медленно. Например, окно выбора папки с изображением дерева каталогов (рис.5.1) или программа поиска файлов (аналог на функциях VBA - объект "Application.FileSearch" - работает слишком медленно при больших количествах файлов). Для таких случаев в VBA предусмотрена возможность вызова функций API.
К сожалению, использование функций API в VBA не документировано в справке, вследствие чего для изучения способов их применения приходится либо искать книги или источники в Интернете по офисному программированию, либо анализировать код программ, в которых имеются вызовы функций API.
В подавляющем большинстве случаев при программировании для Office можно обойтись без использования API, но иногда только вызов API-функции может привести к достижению нужного результата. Скажем, вам надо обеспечить вызов разных макросов при простом нажатии мышью кнопки на какой-либо панели инструментов Word и в случае одновременного нажатия этой кнопки и клавиши Shift или Control. Вот фрагмент кода, делающего это:
Declare Function GetAsyncKeyState Lib "user32.dll" (ByVal kState As Long) As Integer
GetAsyncKeyState (vbKeyShift Or vbKeyControl)
If GetAsyncKeyState(vbKeyShift) Then
Call macro1: Exit Sub
ElseIf GetAsyncKeyState(vbKeyControl) Then
Call macro2: Exit Sub
Первая строчка - это как бы "резервирование" функции API для использования в программе на VBA. Видно, что вызывается функция GetAsyncKeyState из библиотеки (файла, содержащего программы, предназначенные только для использования другими программами) user32.dll, причем в эту функцию передается номер клавиши, а возвращает она целое число (а именно - 0, если клавиша с соответствующим номером не нажата, и -32767 или 1, если нажата). Любую функцию или процедуру, вызываемую из библиотек, не относящихся к VBA, необходимо так резервировать с помощью команды Declare.
Фраза vbKeyShift в команде - это заменитель кода клавиши Shift (его значение - 16), а vbKeyControl, как нетрудно понять - заменитель кода клавиши Control. Структура инструкций "If…Then", думается, ясна 3 , а если нет - посмотрите в справке VBA. Команда Call перед именем макроса, как вы помните, означает его запуск.
В Интернете есть русские сайты, посвященные API 4 . Посетите их, чтобы узнать больше об этом наборе функций.
