API

Практически API выглядит как список адресов и правил обращения к ним. Клиент отправляет запрос — например, GET /orders/123 с токеном в заголовке, — сервер возвращает структурированный ответ в JSON и код состояния: 200, если всё хорошо, 404, если объект не найден, 401 при проблемах с доступом, 429 при превышении лимита. Самые распространённые стили — REST, где данные представлены как ресурсы и адреса, и GraphQL, где клиент сам описывает, какие поля ему нужны, одним запросом.

В коммерческом проекте API — это почти всегда самая недооценённая строка сметы. Через него сайт обменивается данными с 1С, платёжным провайдером, службой доставки, CRM, сервисом рассылок, телефонией. Каждая такая связка — это не «подключить за час», а описание маппинга полей, обработка ошибок и таймаутов, повторные попытки, очередь, логирование и отдельный сценарий на случай, когда чужая система лежит. Именно поэтому интеграции обычно забирают 10–15% бюджета сайта и почти всегда становятся источником срыва сроков, если их оценили «навскидку».

Три ловушки встречаются чаще прочих. Первая — отсутствие документации: если контракт API живёт в голове разработчика, смена подрядчика превращается в реверс-инжиниринг. Вторая — ломающие изменения без версионирования: переименовали поле, и мобильное приложение у половины пользователей перестало работать, потому что обновляются не все и не сразу. Третья — доверие к чужому API как к своему: у стороннего сервиса есть лимиты, деградации и плановые работы, и система должна переживать их без потери заказов, а не отвечать пользователю пятисоткой.

• Документация в машиночитаемом виде (OpenAPI или схема GraphQL), а не в переписке.
• Версионирование и понятная политика устаревания методов.
• Авторизация по токенам с ограниченными правами, а не один ключ «на всё».
• Идемпотентность операций с деньгами: повторный запрос не создаёт второй платёж.
• Лимиты, таймауты, повторные попытки и очередь на стороне вызывающей системы.

Смежные термины

• Headless CMSHeadless CMS — система управления контентом без собственного шаблонизатора: редакторы работают в привычной админке, а сайт, мобильное приложение и любой другой канал получают те же данные через API и рисуют их своим фронтендом.
• МикросервисыМикросервисы — архитектура, где приложение разбито на несколько самостоятельных сервисов со своими базами и релизным циклом: они общаются по сети через API, деплоятся независимо и масштабируются по отдельности, но требуют зрелой инфраструктуры.
• SLASLA — соглашение об уровне сервиса: в нём зафиксированы доступность системы в процентах, время реакции и время устранения по классам инцидентов, часы работы поддержки и компенсации на случай, если подрядчик эти показатели не выдержал.
• Техническое заданиеТехническое задание — документ, фиксирующий, что именно должно быть сделано и по каким признакам работа считается принятой: цели, роли, сценарии, требования по экранам, интеграции, нефункциональные требования и отдельный раздел о том, что в проект не входит.
• AI-агентAI-агент — программа, где языковая модель не просто отвечает, а действует: получает цель, сама выбирает инструменты (поиск, API, база данных, отправка письма), выполняет шаги в цикле и останавливается, когда задача решена или исчерпан лимит.

Услуги по теме

• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.
• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.

Почитать подробнее

• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.
• На чём делать сайт в 2026: Tilda, WordPress, Битрикс или Next.jsКонструктор, CMS или собственная разработка — выбор зависит не от вкуса, а от сценария и горизонта планирования. Разбираем стоимость владения за три года, потолки платформ и цену переезда, если вы ошиблись на старте.