Мой дэйли дайджест

одно техническое понятие в день

API

31 мая 2026 · ~13 мин чтения

концепция интеграции основы веб

API

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

История

Сам термин появился задолго до интернета. По общему мнению, впервые «application program interface» в нынешнем смысле описал британский разработчик Иан Гулд в статье 1968 года про модульную организацию программ — речь шла о наборе процедур, которые одна часть системы предоставляет другим частям. Тогда никаких сетей и облаков не было: API жили внутри одной машины, между функцией A и функцией B.

В 1970–80-е появились первые операционные системы, у которых был чёткий публичный API: программе разрешалось обращаться к ядру через фиксированный набор системных вызовов (read, write, open, close — это всё API ядра Unix). Параллельно росли библиотеки на C: подключаешь stdio.h, получаешь набор функций — это тоже API.

В 1991 году в Cornell придумали CORBA, в 1998 году в Microsoft — DCOM, чуть раньше Sun сделал RPC. Это всё были попытки научить программы на разных компьютерах вызывать функции друг друга через сеть, как будто они в одном процессе. Сложно, тяжело, медленно — но это был первый сетевой API.

Перелом — 2000 год. Рой Филдинг защитил диссертацию «Architectural Styles and the Design of Network-based Software Architectures», где описал стиль REST. Идея простая до неприличия: используем обычный HTTP (GET, POST, PUT, DELETE) и адресуем «сущности» (users, orders, products) как обычные веб-страницы. Это снесло CORBA с рынка за несколько лет.

С 2000-х API стали публичным товаром. eBay открыл API в 2000-м, Salesforce — в 2000-м, Flickr — в 2004-м, Twitter — в 2006-м. В 2006-м Джефф Безос в Amazon издал внутренний приказ (тот самый «Bezos API Mandate»): все команды обязаны общаться между собой только через API, иначе увольнение. Через десять лет это превратилось в AWS — крупнейшую облачную платформу мира.

В 2015 году Facebook опубликовал GraphQL — альтернативу REST, где клиент сам говорит, какие поля ему нужны. В 2016-м Google открыл gRPC — современный потомок RPC, быстрый и бинарный. С тех пор «API» — это огромное семейство стилей, а не один протокол.

Что это такое

API — это договор между двумя сторонами:

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

API бывают сильно разные по уровню абстракции:

Чем API отличается от протокола: протокол — это правила транспорта (HTTP, TCP, MQTT). API — это правила смысла поверх протокола. HTTP — это «как именно перенести байтики», API — это «что эти байтики означают и какие запросы поддерживаются».

Чем API отличается от SDK (Software Development Kit): SDK — это упакованная для конкретного языка библиотека, которая под капотом дёргает API. У Telegram есть HTTP API, а SDK для Python (например, python-telegram-bot) — это удобная обёртка над ним.

Аналогии из жизни

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

Розетка и вилка. Розетка — это API питания. Поставщик электричества обещает: «220 вольт, 50 Гц, два штырька, такой-то размер». Ты не лезешь в стену смотреть, как там тянутся кабели от подстанции. Любой прибор с правильной вилкой работает.
Где ломается: у API больше степеней свободы. В Европе вилка одна, в США другая, в Британии третья — это уже три разных API. То же с веб-API: REST, GraphQL, gRPC — формально все «питание», но переходник нужен. Плюс розетка — обмен в одну сторону, ток идёт в прибор. API — это всегда диалог.

Заказ в МФЦ. Подходишь к окну, говоришь: «хочу справку такую-то», подаёшь паспорт. Сотрудник вбивает что-то в систему, через два дня приходит SMS «справка готова». Ты не знаешь, в какие 14 баз он лазил и кому звонил.
Где ломается: МФЦ может потерять документы, и у тебя нет способа это отследить кроме звонка. У хорошего API всегда есть статусы и идемпотентные повторы: послал запрос, получил «принято» с уникальным id, можешь спросить позже «id такой-то, как там?».

Как это работает

Возьмём самый распространённый случай — REST API поверх HTTP. Кафе делает форму бронирования столиков, у них есть бэкенд, у тебя — мобильное приложение.

Шаг 1. Контракт. Где-то описано (в идеале — в OpenAPI/Swagger спецификации), какие есть методы:

POST   /api/v1/reservations    — создать бронь
GET    /api/v1/reservations/42 — посмотреть бронь
DELETE /api/v1/reservations/42 — отменить

И какие поля принимаются и возвращаются: дата, время, число гостей, имя, телефон.

Шаг 2. Аутентификация. Поставщик хочет знать, кто стучится. Чаще всего — токен в заголовке:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Это JWT, API-key, OAuth-токен — варианты есть, смысл один: пришедший идентифицирован.

Шаг 3. Запрос. Клиент собирает HTTP-запрос:

POST /api/v1/reservations HTTP/1.1
Host: api.cafe.example
Authorization: Bearer eyJ...
Content-Type: application/json

{
  "date": "2026-06-01",
  "time": "19:30",
  "guests": 2,
  "name": "Паша",
  "phone": "+7-999-..."
}

Шаг 4. Обработка на сервере. Бэкенд проверяет токен, валидирует поля (формат даты, есть ли свободные столики), записывает в базу, возвращает ответ:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 42,
  "status": "confirmed",
  "table": 7,
  "expires_at": "2026-06-01T20:30:00+03:00"
}

Шаг 5. Обработка ответа. Клиент смотрит на HTTP-код:

Шаг 6. Идемпотентность. Если запрос потерялся в дороге, клиент его повторяет. Чтобы не создалась вторая бронь, в запрос кладут «идемпотентный ключ» (уникальный id). Сервер запоминает: «по этому ключу я уже отвечал — вот тебе тот же ответ снова». Идемпотентность — это, кстати, отдельная большая тема, мы её разбирали в другой статье.

Шаг 7. Версионирование. Через год кафе захочет добавить новое поле, скажем dietary_preferences. Они не могут просто сломать старых клиентов — поэтому делают новую версию: /api/v2/reservations. Старый эндпоинт продолжает работать, пока всех клиентов не переведут.

Под капотом у HTTP — TCP, у TCP — IP, у IP — Ethernet или Wi-Fi. Это всё «нижние этажи». API живёт где-то ещё на четыре этажа выше: контракт о смысле сообщений, а не о их транспортировке.

Главное про API

API — это не «технология» и не «формат». Это обещание одной системы другой. Технологии (HTTP, JSON, JWT) — лишь инструмент, чтобы это обещание было исполнимо.

Где встречается в обычной жизни

Когда ты залогинился в новый сервис через «Войти через Google». Сервис дёрнул Google OAuth API: «привет, этот пользователь правда тот, за кого себя выдаёт?». Google спросил тебя «можно?», ты согласился, Google вернул сервису токен и базовый профиль.

Когда такси показывает «5 минут до подачи». Приложение водителя пишет координаты в API сервиса, приложение пассажира эти координаты у API запрашивает. API считает расстояние и время.

Когда ты переводишь деньги по СБП с телефона на телефон. Банк-отправитель дёргает API НСПК (Национальной системы платёжных карт), та — API банка-получателя. Три API, чтобы пять секунд погудеть.

Когда в Apple Pay ты прикладываешь часы к терминалу. Терминал по NFC говорит часам «подпиши такой-то платёж», часы дёргают локальный API безопасного элемента, тот — API банка через интернет, банк отвечает «ок», часы возвращают подпись.

Когда ты делишься постом из Instagram в Telegram. Instagram дёргает «Share API» операционной системы. Та опрашивает все приложения, кто умеет принимать ссылку. Telegram отвечает «я умею». ОС показывает иконку. Это даже не сетевой API, а API внутри самого телефона.

Где встречается в IT и бизнесе

Интеграция продукта с чужой инфраструктурой. Например, бот, который пишет лиды в CRM. Лиды копятся у тебя, CRM — у клиента, между ними API. Тебе не нужно лезть в её базу — ты дёргаешь её endpoint «создай контакт».

Платёжная интеграция. Stripe, ЮKassa, Робокасса — у всех есть HTTP API. Ты не пишешь своё кардовое процессирование, ты делаешь POST на /payments. Они в ответ дают ссылку на оплату или статус.

Webhook-callback от внешней системы. Это обратный API: не ты дёргаешь чужой сервис, а он дёргает тебя. Колл-центр обработал звонок — стучится твоему серверу: «по такому-то лиду статус такой-то». Webhook — это просто API, который ты обязался держать поднятым.

API как продукт. Twilio продаёт SMS и звонки — не как сервис «зайди и нажми», а как API. OpenAI продаёт доступ к моделям. Cloudflare — защиту. У SendGrid основная ценность не интерфейс, а API. Бизнес-модель «API как товар» взлетела в 2010-х и сейчас даёт миллиардные обороты.

Внутренние API больших компаний. В Amazon, Google, Яндексе разные команды не лазят в чужие базы, они дёргают API соседней команды. Это даёт независимость: можно переписать сервис с нуля на другом языке, и никто не заметит, пока контракт не меняется.

Кто пользуется

Stripe — обрабатывает API-запросы в количествах, измеряемых сотнями миллиардов в год. Их API стал отраслевым эталоном: красивая документация, продуманные методы, идемпотентные ключи. Многие команды копируют их подход «один в один».

Twilio — за 2024 год через их API прошло свыше 600 миллиардов SMS и голосовых вызовов (по их публичным отчётам). Это компания, которая не имеет ни одного интерфейса для конечных пользователей — только API.

Slack, Discord, Telegram — все три предоставляют публичные API для ботов. Боты Telegram, по разным оценкам, обслуживают сотни миллионов сообщений в сутки. У Slack API более 2 миллионов сторонних интеграций.

Google Maps Platform — обрабатывает миллиарды запросов к Geocoding, Directions и Places API ежесуточно. Без них половина приложений «найди мне X рядом» просто не существовала бы.

Внутри одной компании. В Netflix внутренние сервисы обмениваются сотнями миллионов запросов в секунду. У них даже есть свой API gateway Zuul, который только и делает, что разводит трафик между ними.

Альтернативы и конкуренты

API — это не «продукт», а класс решений. «Альтернативы» здесь — разные стили API:

REST. Плюсы: простой, понятный, любая команда поднимает за день, есть инструменты на любом языке. Минусы: для сложных выборок (нужно 7 полей из 10) приходится делать много мелких запросов или городить параметры.

GraphQL. Плюсы: клиент сам решает, какие поля ему нужны, один запрос покрывает многое. Минусы: сложнее в кешировании, сложнее в защите (можно случайно сделать «жирный» запрос, который убьёт сервер).

gRPC. Плюсы: быстрый (бинарный protobuf), типизированный, отлично для микросервисов. Минусы: плохо работает напрямую с браузером (нужен gRPC-Web), сложнее отлаживать, чем JSON.

Прямой доступ к базе (вместо API). Плюсы: меньше прослоек, быстрее. Минусы: нельзя поменять схему, не уведомив всех; нет контроля доступа на уровне «можно/нельзя»; ломается принцип «инкапсуляция».

Файловый обмен (CSV/XML по FTP). Так до сих пор работают многие банковские интеграции и часть госуслуг. Плюсы: легко аудировать, можно дёшево разово настроить. Минусы: задержка (выгрузка раз в сутки), нет интерактива, тяжело отслеживать ошибки.

Когда НЕ стоит использовать

Когда задержки критичны. API-вызов по сети — это всегда минимум десятки миллисекунд (если оба сервера в одном дата-центре) или сотни (если через интернет). Если ты пишешь высокочастотный трейдинг или игровой движок — там общаются через разделяемую память или внутрипроцессные вызовы.

Когда обмен — массивный батч. Если нужно раз в сутки передать миллион строк, не имеет смысла делать миллион HTTP-запросов. Здесь честнее CSV-выгрузка по S3 или прямой ETL. Один большой файл всегда дешевле миллиона маленьких запросов.

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

Грабли публичного API

Открыть API — значит подписаться на обратную совместимость. Раз ты пообещал, что поле называется customer_id и приходит как строка, ты не можешь это поменять без боли. Все опубликованные API живут версиями (/v1, /v2), и каждая версия — это груз, который ты будешь нести годами.

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера я анализировал, как устроены антифрод-сигналы в проекте БрендБот и связанных сервисах. Большая часть исследования была именно про то, какие данные приходят в HTTP API (/api/visitors, /api/quiz-submitted, webhook_worker), какие API дёргает колл-центр, и как организовать стабильный обмен между ботом, квизом и КЦ. Понятие «API» там было фоном каждой реплики — но именно в этом и важно его понимать.

Краткое резюме