API
API (Application Programming Interface) — программный интерфейс, через который одно приложение запрашивает данные или вызывает функции другого. Основа интеграций CRM, оплат, сервисов доставки.
Определение API
API (Application Programming Interface) — набор правил и эндпоинтов, по которым программы общаются через сеть, не зная внутреннего устройства друг друга. Сайт магазина запрашивает у API склада остатки, у API платёжного шлюза — статус оплаты, у API CRM — историю клиента. Концепция оформилась в 2000-х с распространением SOAP, в 2010-х доминирующим стилем стал REST, с 2015 года растёт GraphQL. По данным RapidAPI, в 2024 году у среднего бизнес-сайта 8–15 активных API-интеграций с внешними сервисами.
Аналогия: API — это меню в ресторане. Клиент выбирает блюдо по описанию, не зная, как устроена кухня. Меню перечисляет, что заказать (эндпоинты), что указать (параметры) и что вернётся (формат данных). Кухню можно переделать — пока меню не меняется, клиент работает.
Виды API: REST, GraphQL, SOAP, WebSocket
API классифицируют по архитектурному стилю — способу, которым клиент и сервер договариваются об обмене.
| Стиль API | Формат | Лучше всего для |
|---|---|---|
| REST | JSON по HTTP, методы GET/POST/PUT/DELETE | Большинство веб-интеграций, мобильные приложения |
| GraphQL | Запрос с указанием нужных полей | Сложный фронтенд с гибкими запросами, экономия трафика |
| SOAP | XML по HTTP | Корпоративные системы 1С, банки, legacy |
| WebSocket | Постоянное двустороннее соединение | Чаты, биржевые котировки, уведомления в реальном времени |
| gRPC | Бинарный Protocol Buffers | Микросервисы внутри одной системы, высокая нагрузка |
Различают также публичные API (открыты всем, как Яндекс Карты), партнёрские (по договору с ключом) и приватные (внутри компании). По данным RapidAPI, на REST приходится около 80% публичных интеграций в вебе — это де-факто стандарт.
Как работает API
Современный REST API передаёт данные через HTTP-запросы в формате JSON, авторизация — через API-ключ или OAuth 2.0. Пример: при оформлении заказа сайт делает POST-запрос к API ЮKassa с суммой и получает URL платёжной формы. API критичны для проектов в сложной разработке и интеграций с CRM и ERP-системами. Документация API — официальный контракт; его нарушение ломает интеграцию.
| HTTP-метод | Действие | Пример |
|---|---|---|
| GET | Получить данные | Запрос остатков товара по артикулу |
| POST | Создать запись | Создание лида в CRM из формы сайта |
| PUT / PATCH | Обновить данные | Смена статуса заказа на «оплачен» |
| DELETE | Удалить запись | Удаление товара из корзины |
Ответ всегда содержит HTTP-код статуса: 200 — успех, 400 — ошибка в запросе, 401 — нет авторизации, 429 — превышен лимит, 500 — ошибка сервера. Грамотная интеграция различает коды и реагирует на каждый по-своему.
Безопасность и метрики
API — открытая дверь в систему, поэтому к ней предъявляют отдельные требования.
- API-ключ и OAuth 2.0 — токены авторизации; ключ хранится только на сервере, не попадает во фронтенд браузера.
- Rate limit — лимит числа запросов: типично 60–600 в минуту для бесплатных API и 10 000+ для платных.
- HTTPS обязателен — данные между клиентом и API шифруются, иначе ключ перехватят.
- Версионирование — /v1/, /v2/ в адресе позволяет менять API, не ломая старых интеграций.
Мини-кейс: магазин синхронизировал остатки с 1С через REST API раз в час и продавал отсутствующий товар — рассинхрон до 60 минут. Переход на webhook от 1С (склад сам шлёт уведомление об изменении остатка) и кэш с TTL 5 минут снизили «продажи в минус» с 40–50 в месяц почти до нуля и убрали ручные возвраты.
Частые ошибки
- Ключ во фронтенде — API-ключ в JavaScript виден любому через DevTools; запросы к стороннему API должен делать бэкенд.
- Нет обработки ошибок и таймаутов — при падении стороннего API пользователь видит зависший спиннер вместо понятного сообщения.
- Опрос вместо webhook — постоянный polling API в цикле жжёт лимиты и даёт задержку; где можно — подписываются на webhook.
- Игнорирование rate limit — при превышении приходит 429, и без backoff-логики интеграция блокируется на минуты.
- Отсутствие версионирования — провайдер меняет формат ответа, и не подготовленная к версиям интеграция падает без предупреждения.
Связанные концепции
- CRM — типовая точка интеграции через API: данные о лидах, сделках и контактах передаются между сайтом и amoCRM или Битрикс24.
- Headless CMS — класс продуктов, где API служит основным способом доступа к контенту.
- Чат-бот — без API остаётся статичным FAQ; именно через API он узнаёт статус заказа, цену и наличие.
- Сквозная аналитика — собирает данные о сделках из CRM и расходах из рекламных кабинетов именно по API.
- Хостинг — от его ресурсов и стабильности зависит, выдержит ли API нагрузку входящих запросов.
Частые вопросы
Сколько стоит разработка API?
Базовый REST API для среднего сайта (10–20 эндпоинтов, авторизация, документация) — от 150 000 ₽ и 4–8 недель. Полноценный API для SaaS с публичной документацией и SDK — 500 000–2 000 000 ₽ и 3–6 месяцев. Готовые сторонние API (Яндекс Карты, ЮKassa) обычно бесплатны до порога нагрузки.
Что делать, если стороннее API упало?
Нужны три вещи. Первое — retry с экспоненциальной задержкой: повтор через 1, 2, 4, 8 секунд. Второе — понятное сообщение пользователю вместо зависшего спиннера. Третье — для критичных операций (оплата, склад) кэшировать последний успешный ответ. Мониторинг через Sentry обязателен.
Чем REST отличается от GraphQL?
В REST для связанных данных делается несколько запросов: /users, /users/1/orders, /orders/5/items — три обращения. В GraphQL один запрос забирает ровно нужное: пользователь, его заказы и товары в каждом заказе одним вызовом. GraphQL экономит трафик и удобен для мобильных. REST проще в реализации и остаётся стандартом для большинства публичных API.
Безопасно ли хранить API-ключ на сайте?
Frontend-код виден всем через инструменты разработчика, поэтому в браузере ключи хранить нельзя. Правильное решение — запросы к стороннему API делает ваш сервер, а ключ лежит в его переменных окружения. Если ключ утёк, нужны немедленная ротация (выпуск нового и отзыв старого) и проверка логов на подозрительные запросы.
Что такое OpenAPI и Swagger?
OpenAPI (бывший Swagger) — стандарт описания API в YAML или JSON. Из спецификации генерируются интерактивная документация (Swagger UI), SDK на разных языках и mock-сервер для тестов фронтенда без бэкенда. К 2024 году OpenAPI 3.x стал индустриальным стандартом документирования REST API.
Чем webhook отличается от обычного API?
Обычный API работает по запросу: вы спрашиваете — он отвечает. Webhook наоборот: вы один раз даёте провайдеру URL, и он сам шлёт на него уведомление при наступлении события, например прошла оплата. Это убирает постоянный опрос в цикле, экономит лимиты и даёт мгновенную реакцию. Минус — сервер должен быть доступен извне для приёма запросов.