API — это программный интерфейс приложения и одно из ключевых составляющих почти любого современного корпоративного программного обеспечения или интернет-магазина. Что способствует такому широкому распространению API, каковы их задачи и преимущества использования. Во всех этих вопросах постараемся разобраться в сегодняшней статье.
Прежде всего нужно отметить, что все API могут быть разделены на публичные и приватные, а также внешние и внутренние. Также API могут оперировать различными форматами данных, такими как JSON, XML и другие менее распространенные, а также работать с различными протоколами, однако в последнее время наибольшую популярность и даже некий стандарт в проектирование современного API можно назвать использование архитектуры RESTfull-сервисов, которые предполагают использование HTTP\HTTPS в качестве протокола передачи данных.
API представляют собой некую систему или совокупность систем, которая функционирует на стороне сервера. То есть этот код, обычно, не доступен для чтения, а наоборот, скрыт для большинства пользователей. Данный код, в свою очередь, генерирует совокупность данных, которая может быть представлена как в структурированном, так и в произвольном виде. Получить же необходимую информацию, можно послав специально сформированный запрос на определенный конечный узел (end point). В общем виде это может быть обычный HTTP\HTTPS-запрос с дополнительными параметрами. Например:
https://some-restfull-services-server.com/api_v1/get_all_hotels?country=USA&states=California,Texas,Florida&stars=3,4,5&rooms=3&launch=true&checkpayment=true
Такой запрос к воображаемому источнику API отелей в США может содержать фильтрацию запрашиваемых данных, которая может быть сформирована в виде GET-параметров HTTP\HTTPS запроса. Также могут применяться и POST параметры, однако POST, также как UPDATE и DELETE методы HTTP протокола применяются для других операций с API (передачу данных, а также их обновление и удаление). Хочется сразу отметить, что операции обновления и удаления данных обычно не используются в публичных API, которые доступны, в большинстве случаев, только на чтение. К таким API, можно, например, отнести прогноз погоды, информацию об акциях и ценных бумагах, коэффициенты выигрыша на ставках, информацию о спортивных матчах, цены на различные товары и услуги и многое другое. Такая информация может быть охарактеризована большим числом систем-потребителей (например корпоративные приложения, десктопные и мобильные приложения), которые могут ее использовать для дальнейшей обработки.
Публичные API не требуют пароля или какого-либо другого идентификатора, а потому могут использоваться одновременно тысячами и даже миллионами устройств, поэтому к проектированию публичных API должны предъявляться особые требования к отказоустойчивости и пропускной способности сервера. Одним из самых популярных решений для подобных задач является ограничение на количество запросов, которое может быть произведено с одного IP-адреса или пользователя. Такой подход позволяет более точно предсказать максимальную нагрузку на сервер, а значит существенно улучшить быстродействие конечного API. Некоторые публичные API позволяют запросить данные в различном формате, например в таких как JSON и XML. Это бывает полезно, когда система-потребитель (или система-клиент) может работать только с одним из них, однако поддержка таких API намного более трудозатратна. Формат ответа от API также может быть различен по количеству непосредственно передаваемых байт, так как разные форматы могут содержать больше или меньше синтаксического сахара (синтаксические конструкции, которые фактически и задают тот или иной формат данных). JSON, в связи с этим, имеет неоспоримое преимущество на фоне его «коллег». Вот так может выглядеть ответ на вышеприведенный запрос к API отелей в США:
{
"gen_timestamp": 1510729858.8067338,
"pois": [
{
"id": 70643,
"rating": 0,
"category": "airport",
"name": "Koggala Airport",
"location": {
"lat": 5.983056,
"lon": 80.33305
},
"geom": {
"type": "Point",
"coordinates": [
80.33305,
5.983056
]
},
"confirmed": true
}
],
"hotels": [
{
"id": 1399511245,
"cityId": 895,
"stars": 0,
"pricefrom": 30,
"rating": 0,
"popularity": 900,
"propertyType": 6,
"checkIn": "14:00",
"checkOut": "12:00",
"distance": 6,
"photoCount": 9,
"photos": [
{
"url": "http://photo.hotellook.com/image_v2/limit/h1399511245_8/320/240.auto",
"width": 320,
"height": 240
}
],
"photosByRoomType": {},
"yearOpened": null,
"yearRenovated": null,
"cntRooms": null,
"cntSuites": null,
"cntFloors": null,
"facilities": [
7
],
"shortFacilities": [],
"location": {
"lon": 81.201033,
"lat": 6.208641
},
"name": {
"en": "Sayonara Resorts"
},
"address": {
"ru": "Sayonara Resorts - Pallemalala , Weligatta , Hambantota., Тиссамахарама",
"en": "Sayonara Resorts - Pallemalala , Weligatta , Hambantota."
},
"link": "/lk/weerawila-895/sayonara_resorts-1399511245.html",
"poi_distance": {
"70642": 96987,
"70643": 99193,
"70650": 57116
}
}
]
}
Приватные же API обычно используются для передачи данных в пределах одного приложения или системы, а также могут использоваться для клиентов-партнеров. В данном случае такие API будут запрашивать аутентификационные данные, такие как пару логин\пароль, ключ или иной идентификатор. В данной статье мы не будем подробно рассматривать варианты аутентификации, так как эта область заслуживает отдельной статьи. В большинстве сегодняшних веб-приложений сложно найти такое, которое вообще не будет использовать какое-либо API. Так, например, спортивные букмейкеры используют данные о спортивных событиях, интернет-магазины — данные валюты, билетные агрегаторы — данные перевозчиков. Приватные API, таким образом, имеют endpoint-ы как на чтение, так и на изменение данных. Приватные API также могут быть использованы для взаимодействия двух и более сервисов, которые работают на серверной стороне приложения, или, проще говоря по back-to-back принципу взаимодействия. Никаких существенных отличий, правда, такое взаимодействие не имеет, относительно того, когда ответ API выводится на какое-либо устройство вывода или интерфейс. Внутренние API используются для взаимодействия как отдельных сервисов конечного приложения, так и между разными приложениями одной компании или компаний-партнеров.
Предположим у компании-агрегатора по бронированию отелей существует партнеры. Они могут заниматься сервисным обслуживанием, доставкой еды или предоставлять аренду транспортных средств. В таком случае приложение-агрегатор, возможный end point которого мы рассматривали выше может также иметь end point-ы для взаимодействия с партнерами. То же самое касается и приложений партнеров — они могут иметь закрытое приватное API для взаимодействия с сервисами других компаний.
Итак, давайте рассмотрим основные преимущества использования API для приложений:
- Использование API позволяет отделить бизнес-логику от представления (интерфейса), а значит одна и та же бизнес-логика может быть использована несколькими интерфейсами, например веб, мобильным, десктопным и другими;
- Современные API используют унифицированный формат данных и протоколы передачи данных, что позволяет переиспользовать уже существующие программные обработчики и ускорить подключение и работу с новыми API, а также использовать стандартные алгоритмы защиты при передаче данных;
- Использование API позволяет повысить отказоустойчивость приложения в целом в следствие первого пункта;
- API позволяет произвести быструю кооперцию с партнерами и потребителями, что способствует многократному приросту функциональности в минимальные временны’е сроки;
- API позволяет организовать многоролевую систему доступа к данным для сторонних и внутренних сервисов;
- Одно и тоже API может быть использовано для построения различной конечной бизнес-логики;
Следует также заметить, что построение любого API, как публичного, так и приватного, требует опытных квалифицированных специалистов. Creative Lab рад предложить свои услуги в создание API любой сложности.
Больше информации о нас можно получить на главной странице.
