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

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

Знакомая ситуация из реальной жизни

Представь, что мы хотим запустить свой маркетплейс. И��ея простая: на нашей площадке сотни разных поставщиков смогут размещать и продавать свои товары. А покупатели смогут в одном месте найти все что угодно. Что-то типа WB или Ozon.

Для покупателей мы, конечно, сделаем удобный сайт. Это будет наш пользовательский интерфейс (или UI). Хочешь найти товар? Вот тебе строка поиска. Увидел что-то интересное? Вот кнопка «Добавить в корзину». Решил купить? Кнопка «Оформить заказ».

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

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

Но что насчет поставщиков товаров?

Скорее всего, у каждого поставщика уже есть своя собственная программа, где они ведут учет товаров, сколько их на складе, какая политика цен. У кого-то это 1С, у кого-то «МойСклад», кто-то вообще использует что-нибудь самописное. И вот они хотят разместить свои товары у нас. Но товаров у них много — десятки тысяч.

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

И вот наш поставщик смотрит на это и думает:

«Вы серьезно? У меня 10 000 товаров, и вся информация о них уже хранится в МОЕЙ программе. Вы предлагаете мне целый месяц сидеть и вручную копировать каждый товар из моей программы в вашу через эти кнопочки? Это же безумие!»

И он абсолютно прав. Это долго, дорого и стопроцентно приведет к ошибкам. О чем мечтает такой поставщик?

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

Как же это сделать?..

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

Чтобы его программа могла отдавать команды нашему маркетплейсу, а не он сам. Но у его программы нет глаз и рук. Для нее интерфейс с кнопками — бесполезен. Значит, нужен какой-то другой…

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

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

Каждая розетка — для своей задачи.

• Первая розетка, допустим, отвечает за добавление новых т��варов. Программа поставщика «втыкает свой штекер» в эту розетку и передает по проводу данные. Всё, что приходит в него через эту розетку, наш маркетплейс считает новым товаром и добавляет на витрину.

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

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

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

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

Любое приложение создает такой набор «розеток», который и называется API. Это буквально Программный Интерфейс Приложения. То есть, набор способов отдавать ком��нды нашему приложению извне.

Но в отличие от пользовательского интерфейса, команды здесь отдают не люди, а другие программы. Поэтому он и называется «программный интерфейс». А по-английски — Application Programming Interface. Сокращенно — API. И все это нужно, чтобы другие программы могли с ним общаться автоматически.

Теперь учетная система поставщика сама, без участия человека, «втыкается» в нужную розетку и отправляет данные о новом товаре. Но, разумеется, это не просто случайный текст.

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

Вот как может выглядеть информация о товаре в таком формате:

{
  "название": "Боевой Хомяк (ручной)",
  "цена": 15000,
  "количество": 350
}

Теперь, когда поставщик добавляет новый товар у себя в программе, его система сама автоматически формирует такое сообщение и отправляет в нашу «розетку». И не по одному!

Программа поставщика может сразу подготовить 10 000 таких сообщений, упаковать их в один большой пакет и отправить его нам. Наш API его получит, быстро обработает все 10 000 товаров и сохранит их у себя. И все это за секунду! Не пришлось руками ничего тыкать.

Но как сделать свой API?

Но что буквально в коде является такой вот «розеткой»? Как мы, разработчики приложений, создаем свой API?

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

function добавитьТовары(товары) {
  database.save(товары);
}

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

Но вот проблема: эта функция находится внутри нашего приложения. Как программе поставщика вызывать ее? Она ведь не может просто так дотянуться до нашего кода и дернуть нашу функцию.

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

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

Но как дать внешней программе возможность вызывать функции в нашем коде?

Что если мы дадим нашей функции публичный адрес в интернете? У нашего сайта же есть главный адрес в интернете. Например: marketplace.com. Переходишь по нему в браузере — видишь главную страницу нашего маркетплейса.

Но можем же мы создать такие же интернет-адреса для отдельных функций нашего приложения?

Например, пишешь адрес в браузере - marketplace.com/products , жмешь Enter, и в коде приложения вызывается конкретно функция добавитьТовары().

То есть привяжем к этой функции строчку /products. Если она указана в адресе — приложение понимает, что нужно вызвать функцию, помеченную такой строкой.

И также поступим с другими функциями! Для функции обновления цен сделаем свой адрес, например, /prices. Для получения отчетов — свой, /reports. Тогда у каждой функции будет свой уникальный, но доступный публично адрес. То есть по этому адресу может перейти кто угодно в интернете.

@address("/products")
function добавитьТовары(товары) {
  //...
}

@address("/prices")
function обновитьЦену(цена) {
  //...
}

@address("/reports")
function получитьОтчеты() {
  //...
}

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

Этот публичный адрес для конкретной функции и называется Эндпоинт (Endpoint).

Создавать такие публичные адреса-эндпоинты можно в любом языке программирования с помощью специальных библиотек-фреймворков. Например, для Java есть фреймворк Spring, который позволяет легко объявлять эндпоинты. В Python для этого есть фреймворк Django. И так далее.

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

Но что это нам дает? Теперь, когда у нашей функции есть публичный адрес в интернете, то обратиться к нему может не только человек, но и любая программа! Программа поставщика может у себя в коде просто содержать этот адрес - ведь это всего лишь обычная строка - все точно скомпилится.

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

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

У твоего приложения появляется второй интерфейс. Один — для пользователей (UI), а второй — для других программ (API).

Кто может использовать наш API?

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

То, что ты видишь в своем браузере — красивые кнопочки, картинки товаров, менюшки — это Фронтенд (Frontend). Это наша «витрина магазина». По сути это просто специальная программа для визуального оформления приложения.

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

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

Куда? Зачем?

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

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

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

Поэтому ты пишешь отдельную программу, например, на языке Java или Go, и именно в ней содержится вся сложная и тяжеловесная логика твоего приложения. Бекенд — это сила, но он невидимый, находится как бы сзади фронтенда, так как пользователь видит визуал только. Оттуда и названия: front — спереди, а back — сзади. Все из английского.

А теперь главный вопрос: если фронтенд — это отдельная программа на языке JavaScript, а бэкенд — это полностью другая программа, например, на языке Java, то как они общаются между собой? Когда ты жмешь кнопку «Купить» на витрине, как эта команда долетает до склада, чтобы товар списался из базы данных?

Конечно, с помощью того же самого API!

Наш бекенд предоставляет набор «розеток» не только для внешних поставщиков, но и для своего собственного фронтенда!

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

Когда ты заходишь на главную страницу, наш фронтенд тут же обращается к «розетке» бекенда по адресу /products/list , который привязан к функции получения списка всех товаров на бекенде.

Бекенд получает обращение через это соединение, обрабатывает и в ответ шлет информацию о конкретных товарах обратно по тому же соединению. Фронтенд получает эти данные и красиво рисует их на странице.

А жмешь кнопку «Купить» — фронтенд отправляет данные о товаре в «розетку» /orders на бекенде, где к этому адресу привязана функция оформления заказа и оплаты.

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

Заключение

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

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

Спасибо!