Api что означает

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

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

Этот краткий термин на слуху у всех, кто хоть как-то сталкивался с разработкой. Но далеко не все понимают, что именно он обозначает и зачем нужен. Разработчик Пётр Газаров рассказал об 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

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

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

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

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

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

Что такое API

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

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

Что такое API

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

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

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

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

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

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

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

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

Тут вы можете мне сказать:

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

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

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

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

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

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

Можно не группировать вообще, а делать одно общее API.

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

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

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

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

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

Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:

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

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

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

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

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

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. Для проверки логики без докруток фронта

Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!

Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.

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

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

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

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

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

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

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

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

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

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

Резюме

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

API классификация масел

API (American Petroleum Institute) — Американский Институт Топлива. Организация, которая сертифицирует и лицензирует моторные масла. Также API занимается разработкой современных новейших спецификаций и определяет минимальный набор стандартов качества моторных масел для бензиновых и дизельных двигателей, а также для базовых масел.

API классы для бензина и дизеля

С 1947 не без помощи ученных института API было принято (и действует до сих пор) разделение моторных масел по API классификации на бензиновые — S, и дизельные — C. Со временем качество масел совершенствовалось, требования — повышались, что непосредственно отзывалось в маркировке масел. API Service SA, SB, SC, SD, SE, SF, SG, SH, SJ, SL, SM, SN — это все о моторных маслах для бензинового двигателя. API СA, СB, СC, СD, СD-II, СE, СF, СF-2, СF-4, СG-4, СH-4, CI, CI-4, СJ-4 — разумеется, моторные масла для дизельных двигателей. Каждая следующая (по алфавиту) буква в классификации API означает следующий виток развития масляной индустрии, и более жесткие требования к качеству.

Замещение классов в API-классификации

Для себя надо отметить, что каждый следующий класс подразумевает замещение предыдущего, для дизелей с учетом «тактности» ( в классе СF-2 — двойка означает «для двухтактных дизельных двигателей», а в классе СJ-4 — «моторное масло для четырехтактных дизельных двигателей»). Так как большинство моторных масел можно с одинаковым успехом применять и в бензиновых и в дизельных двигателях, применяется такая маркировка API CJ-4, CI-4, CH-4, CG-4/SM. Класс, прописанный первым, является основным, т.е. — моторное масло для дизельных двигателей, но возможно применение в бензиновых двигателях, соответствующих классификации API SM.

Дополнения к API-классификации

На одном разделении моторных масел на бензиновые и дизельные API не остановились. С совершенствованием технологий производства современных двигателей повышались и требования, предъявляемые к моторным маслам. Поэтому API создают новые стандарты и спецификации, а также организации, которые лицензируют производителей моторных масел и сертифицируют их продукцию. Как пример: ILSAC GF или Energy Conserving (EC). Данные спецификации являются новейшими в API классификации.

API SM. Требования

Главные требования, предъявляемые для моторных масел класса API SM, во многом совпадают с требованиями ILSAC GF-4. Потому принято считать, что классификация API SM соответствует ILSAC GF-4. Требования, выполнение которых обязывает классификация API SM ILSAC GF-4 по сравнению с предыдущим классом API SL, выражаются приблизительно так:

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

Итак. Моторное масло, удовлетворяющее требования классификации API SM ILSAC GF-4, может применяться в бензиновых двигателях автомобилей, выпущенных после 2004 года. Если производителем не указаны дополнительные требования, вполне возможно применение масел API SM ILSAC GF-4 и в более старых моделях двигателей.

API SN классификация

Главной причиной появления класса API SN является необходимость совершенствования моторных масел вообще. Производители двигателей с каждым днем «наворачивают» моторы все больше и больше. Само собой разумеется, масла для таких моторов нельзя оставлять без изменений. Отсюда явление миру API SN. Моторные масла, сертифицированные как соответствующие API SN, подразумевают возможность применения во всех бензиновых двигателях современного поколения (не забывайте о допусках производителя, определенных для Вашего авто).

Требования API SN

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

моторные масла, лицензированные API SN, можно применять в двигателях, использующих биотопливо
класс API SN обязывает моторные масла быть энергосберегающими
API SN предъявляет дополнительные требования к обеспечению износостойкости двигателя
моторные масла API SN должны обеспечивать «долгую и счастливую жизнь» системам контроля эмиссии и «экологически чистый» выхлоп 🙂
Отличительной чертой API SN (по сравнению с API SМ) является совместимость с уплотнительными элементами двигателя. Еще совсем недавно классификация API не особо заботилась о сохранении сальников и прокладок. Теперь все по-другому. API SN подразумевает контроль за РТИ двигателя.

Интересное о API SN

Последние интересные факты о классе API SN. На стенде, который непосредственно отвечает за испытания моторных масел (тот самый стенд, через который должны пройти все моторные масла, борющиеся за «почетное звание» — API Service), сменили тестовый двигатель! Вместо V-образной фордовской восьмерки объемом 4.6 литра 1993 года (царя Гороха выпуска 🙂 ) была введена 3.6-литровая V-образная шестерка 2008 года от General Motors. Это, конечно, новость! А вот то, что API SN может заменить все предыдущие классы API (API SМ, API SL и т.д. и т.п.) — пожалуй, не новость, но — факт.

класс API SL

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

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

«Соседство» API SL вместе с CF на этикетке (часто встречается API SL CF) — это возможность применения масла и в дизельных двигателях (подробнее о API CF). Никак не умаляя «бензиновых» свойств, моторное масло API SL CF готово к применению в дизельном двигателе, даже с применением топлива с высоким содержанием серы (высокосернистым 0,5% и более). Относится к дизелям 1994 года и позже.

API SL ILSAC GF-3

Масла API SL (в смысле, соответствующие API SL) могут быть сертифицированны по категории ILSAC GF-3, что говорит о экономии топлива и сохранение этой экономии на весь срок эксплуатации масла.