API (официант в ресторане)

На пальцах

Ты приходишь в ресторан и садишься за стул. Кухня, где готовят еду, обычно закрыта для посетителей — туда не пускают. Но ты можешь получить любое блюдо из меню. Между тобой и кухней ходит официант. Ты говоришь ему: «стейк средней прожарки, без грибов» — он знает, как передать заказ поварам. Через 15 минут возвращается с тарелкой. Кухни ты не видишь, но еду получаешь.

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

Что это

API (Application Programming Interface — программный интерфейс приложений) — это набор правил и способов, которыми одна программа может попросить другую программу что-то сделать и получить результат. «Интерфейс» здесь означает договор между программами: какие запросы можно посылать, в каком виде, и что придёт в ответ.

Зачем

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

Без API каждое приложение подключалось бы к базе напрямую и разбиралось в её внутренностях по-своему. С API формат запросов и ответов зафиксирован один раз — и любая программа пользуется им одинаково.

Ещё API умеет:

принимать запросы на создание, изменение и удаление данных (CRUD)
возвращать ответ в стандартном формате (JSON или XML)
проверять, что запрос пришёл от «своего» (авторизация по токену или ключу)
сообщать, что пошло не так (коды ошибок: 404, 500 и т.д.)
ограничивать, сколько запросов в минуту можно делать (rate limiting)
работать по разным правилам обмена — например, REST, GraphQL или gRPC