Подход API-first: почему современный сайт всё реже существует сам по себе

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

• CRM;
• ERP;
• телефонией;
• payment-системами;
• analytics;
• email;
• AI;
• mobile apps;
• внутренними кабинетами;
• партнёрскими сервисами.

Поэтому при разработке всё важнее становится не только вопрос: Как будет выглядеть сайт? Но и другой: Как сайт будет обмениваться данными с остальными системами бизнеса? Именно здесь появляется подход API-first . Что значит API-first API-first означает, что сначала проектируется не интерфейс страницы, а контракт данных и взаимодействия между системами. То есть команда заранее определяет:

• какие данные существуют;
• какие сущности есть в системе;
• какие операции разрешены;
• какие запросы может выполнять клиент;
• какие ответы возвращает backend;
• как обрабатываются ошибки;
• как работает авторизация;
• как версионируется API.

И только после этого вокруг API могут существовать разные интерфейсы: Web Mobile Admin Partners В результате бизнес-логика не привязана к одному сайту. Она становится самостоятельным слоем платформы. Простой пример Допустим, у компании есть каталог услуг. В старой архитектуре логика каталога может быть встроена прямо в сайт. Страница сама:

• получает данные;
• применяет правила;
• формирует цены;
• определяет доступность;
• показывает результат.

Пока интерфейс один, это работает. Но затем появляется мобильное приложение. И возникает вопрос: Откуда mobile будет получать те же данные? Если логика была зашита в frontend сайта, её придётся дублировать. Потом появляется административный интерфейс. Потом партнёрский кабинет. Потом Telegram-бот. И бизнес начинает поддерживать несколько реализаций одной и той же логики. API-first решает проблему иначе. Есть единый backend. Он знает:

• какие услуги существуют;
• сколько они стоят;
• кому доступны;
• какие правила действуют;
• какие данные нужно вернуть.

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

• сайт;
• мобильное приложение;
• менеджерскую панель;
• партнёрский кабинет;
• API интеграции;
• AI-ассистента.

Интерфейсы разные. Бизнес-правила одни. Это особенно важно, когда правила начинают усложняться. Например:

• скидки;
• роли;
• статусы;
• доступность;
• лимиты;
• валюты;
• налоги;
• проверки.

Если всё это дублируется в нескольких frontend-приложениях, система быстро становится трудноуправляемой. Если правила находятся в одном месте, сопровождение проще. Сайт как интерфейс CRM Возьмём обычную форму заявки. Для пользователя это несколько полей:

• имя;
• телефон;
• комментарий.

Но внутри бизнеса сценарий может быть гораздо длиннее. После отправки формы:

1. данные валидируются;
2. создаётся lead;
3. он попадает в CRM;
4. назначается менеджер;
5. отправляется уведомление;
6. событие записывается в аналитику;
7. запускается email;
8. создаётся задача на follow-up.

То есть форма на сайте — только начало процесса. API связывает frontend с бизнес-системой. Пользователь видит одну кнопку. Бизнес получает автоматизированный workflow. Связь с ERP Для ecommerce или сложных B2B-систем сайт часто зависит от ERP. Например, ERP хранит:

• остатки;
• цены;
• заказы;
• контрагентов;
• документы;
• логистику.

Если сайт работает отдельно, данные приходится синхронизировать вручную. Возникают проблемы:

• на сайте товар есть, а на складе уже нет;
• цена отличается;
• заказ не попал в учётную систему;
• менеджер переносит данные вручную.

Через API сайт может получать актуальное состояние напрямую. Тогда пользовательский интерфейс отражает реальный бизнес-процесс. Телефония Телефония тоже всё чаще становится частью цифрового продукта. Например: пользователь оставляет заявку. CRM создаёт карточку. Телефония связывает звонок с этой карточкой. Менеджер видит:

• кто звонит;
• откуда пришёл клиент;
• какие страницы он смотрел;
• была ли предыдущая заявка.

Без интеграций это набор отдельных сервисов. С API — единая цепочка данных. Payments Платёжная система — ещё один пример. Сайт может:

• создать заказ;
• отправить его на оплату;
• получить статус;
• обновить состояние заказа;
• передать событие в CRM;
• отправить чек;
• обновить аналитику.

Здесь особенно важно, чтобы бизнес-логика не находилась только в интерфейсе. Frontend не должен быть единственным источником истины о том, оплачен заказ или нет. Этим должен управлять backend. Analytics В современной системе аналитика тоже должна быть частью архитектуры. Не просто установить счётчик. А определить:

• какие события важны;
• какие сущности отслеживаются;
• какие идентификаторы передаются;
• как связать сайт с CRM;
• как определить реальную продажу.

Например, маркетинг видит: Пользователь отправил форму. Но бизнесу важнее знать: Эта заявка превратилась в сделку на 500 000 ₽. Для этого данные должны пройти цепочку: Web → CRM → Sale → Analytics Без интеграции сайт показывает только начало пути. С API можно связать маркетинговые события с реальным бизнес-результатом. Email и автоматизация Email тоже редко работает отдельно. После определённого события система может автоматически отправить:

• подтверждение заявки;
• invoice;
• onboarding;
• напоминание;
• документ;
• статус заказа.

Главное здесь — событие. API-first архитектура позволяет строить процессы вокруг событий, а не вокруг конкретной страницы сайта. Например: order.created может одновременно:

• создать запись в CRM;
• запустить email;
• отправить событие в analytics;
• уведомить менеджера.

Одна операция запускает несколько систем. AI как новый интерфейс AI делает API-first ещё важнее. Раньше интерфейсами были:

• web;
• mobile;
• admin.

Теперь к ним добавляется AI. Например, пользователь пишет: Покажи мои последние заказы. AI не должен сам искать данные в интерфейсе сайта. Он обращается к API. И получает структурированный ответ. Или менеджер спрашивает: Какие лиды сегодня требуют ответа? AI может запросить CRM через API и вернуть результат. Таким образом, AI становится ещё одним клиентом существующей бизнес-логики. Если система изначально API-first, подключить такой интерфейс проще. Если вся логика зашита в страницы, интеграция становится намного сложнее. Mobile apps

Мобильное приложение особенно хорошо показывает ценность API-first. Без общего API часто возникает такая ситуация: Web-команда реализовала одну логику. Mobile-команда — другую. Через несколько месяцев:

• цены отличаются;
• статусы работают по-разному;
• проверки отличаются;
• одна платформа уже поддерживает новую функцию, другая нет.

Если основные бизнес-правила находятся на backend, обе платформы используют один источник истины. Тогда: Web и Mobile остаются интерфейсами одной системы. Admin Административный интерфейс тоже не должен быть отдельной системой с собственной логикой. Менеджер, администратор и клиент могут видеть разные интерфейсы, но работать с одними данными. Например: клиент видит свой заказ в Web. Менеджер меняет статус через Admin. Мобильное приложение сразу получает новое состояние. Это возможно, если все интерфейсы работают через один backend.

Partners API-first особенно полезен, когда появляются партнёры. Например, бизнес хочет разрешить другим компаниям:

• получать каталог;
• создавать заказы;
• проверять статусы;
• получать цены;
• передавать клиентов.

Если система изначально построена вокруг API, партнёрский доступ можно добавить как ещё один клиент. Если же сайт монолитный и вся логика находится внутри страниц, подключение партнёра превращается в отдельный проект. Почему API-first снижает дублирование Одна из главных инженерных выгод — меньше повторяющейся логики. Плохой сценарий: Web считает цену сам. Mobile считает цену сам. Admin считает цену сам. В результате появляются три реализации одного правила. Рано или поздно они начинают расходиться. Хороший сценарий: есть endpoint:

POST /calculate-price Он применяет единые правила. Web использует его. Mobile использует его. Admin использует его. Меняется правило — меняется один backend. Контракт данных важнее конкретного интерфейса API-first заставляет заранее ответить на важные вопросы. Например: что такое Customer? Что такое Order? Какие статусы есть у Lead? Какие поля обязательны? Какие данные можно менять? Какие ошибки возможны? Это дисциплинирует архитектуру. Вместо случайного набора форм и таблиц появляется понятная модель предметной области. Например: Customer

Lead Order Payment Product Invoice Дальше разные интерфейсы работают уже с этими сущностями. API-first не значит «делать API ради API» Важно не превращать архитектуру в самоцель. Если у бизнеса простой лендинг на пять страниц, отдельная сложная API-платформа может быть избыточной. Архитектура должна соответствовать задачам. API-first особенно полезен, когда:

• продукт развивается;
• есть несколько интерфейсов;
• нужны интеграции;
• есть мобильное приложение;
• работает CRM;
• появляются партнёры;
• используется AI;
• бизнес автоматизирует процессы.

То есть когда сайт перестаёт быть просто страницами. Пример архитектуры Современная система может выглядеть так: Backend / API хранит:

• данные;
• бизнес-логику;
• роли;
• правила;
• статусы.

К нему подключаются: Web публичный сайт. Mobile мобильное приложение. Admin панель сотрудников. CRM работа с лидами. ERP учёт. Payments оплата. Analytics события и показатели. AI ассистенты и автоматизация. Partners внешние сервисы. В центре находится не конкретный интерфейс. В центре находятся данные и бизнес-правила. Что получает бизнес

1. Быстрее запускать новые интерфейсы

Если API уже существует, запуск нового frontend не требует переписывать всю систему. Например, можно добавить:

• mobile app;
• kiosk;
• partner portal;
• AI assistant.

Они используют уже существующую логику.

2. Меньше дублирования

Одни правила работают для всех интерфейсов. Меньше риск, что сайт и приложение начнут вести себя по-разному.

3. Проще менять frontend

Можно полностью заменить визуальный слой, сохранив backend. Это особенно полезно при redesign. Например: старый frontend → новый frontend при этом:

• данные;
• CRM;
• API;
• бизнес-логика;

остаются.

4. Проще подключать внешние сервисы

CRM, ERP, payment или AI не нужно интегрировать напрямую в каждую страницу. Они взаимодействуют с API.

5. Проще масштабировать продукт

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

• понятные contracts;
• authentication;
• authorization;
• validation;
• versioning;
• documentation;
• error handling;
• monitoring;
• tests.

Например, если API меняется без versioning, обновление backend может внезапно сломать mobile app. Если нет документации, подключение нового клиента занимает недели. Если права не продуманы, интеграции становятся риском для безопасности. Поэтому API — это продукт внутри продукта. API documentation Хороший API должен быть понятен не только его автору. Документация должна объяснять:

• endpoints;
• параметры;
• модели данных;
• ошибки;
• authorization;
• примеры запросов;
• ограничения.

В современных проектах часть документации можно генерировать автоматически через:

• OpenAPI;
• Swagger;
• schema definitions.

Это сокращает стоимость подключения новых команд и сервисов. API и безопасность API-first делает особенно важной модель прав. Нужно чётко разделить: authentication кто обращается к системе? и authorization что этому клиенту разрешено? Например: пользователь мобильного приложения может читать свои заказы. Менеджер — заказы своего отдела. Администратор — все. Партнёр — только заказы, созданные через его интеграцию. Если API правильно проектирует доступ, разные интерфейсы могут безопасно работать с одной платформой. API-first и модернизация legacy

API-first полезен не только при создании новых систем. Он может быть стратегией модернизации старых. Например, есть legacy CMS. Полностью заменить её слишком дорого. Можно постепенно создать API вокруг существующей системы. Затем подключить новый frontend. Получается: Legacy CMS + API + New Frontend Дальше старые компоненты можно заменять постепенно. Это позволяет модернизировать продукт без большого одномоментного rebuild. Сайт больше не центр системы В старой модели сайт был главным цифровым продуктом бизнеса. В новой модели сайт — один из каналов доступа к данным и функциям.

Сегодня клиент может взаимодействовать с компанией через:

• browser;
• mobile app;
• messenger;
• phone;
• AI assistant;
• partner platform.

Все они должны видеть согласованные данные. Поэтому центр архитектуры смещается. Не: Сайт и всё вокруг него. А: Платформа и несколько интерфейсов вокруг неё. Подход VERB В VERB мы стараемся смотреть на сайт не как на изолированный набор страниц. Мы смотрим на него как на часть цифровой системы бизнеса. Перед разработкой важно понять:

• откуда приходят данные;
• куда уходят заявки;
• какие системы уже существуют;
• какие интеграции понадобятся позже;
• нужна ли mobile-версия как отдельный продукт;
• будут ли партнёры;
• нужен ли AI;
• кто управляет бизнес-логикой.

После этого можно решить, какая архитектура действительно нужна. Иногда достаточно обычного server-rendered сайта. Иногда нужен отдельный API. Иногда — полноценная платформа. Главное — не строить архитектуру только вокруг сегодняшней страницы, если завтра бизнесу понадобится пять новых интерфейсов. Главный тезис API-first — это не про то, чтобы сделать сайт сложнее. Это про то, чтобы один раз определить бизнес-логику и использовать её в разных каналах. Получается простая модель: одни данные одна бизнес-логика = много интерфейсов

Web. Mobile. Admin. Partners. AI. Именно поэтому современный сайт всё реже существует сам по себе. Он становится одним интерфейсом большой цифровой системы бизнеса.

Планируете сайт, CRM, mobile или новые интеграции?

VERB может провести архитектурный аудит и определить:

• какие данные должны быть общими;
• что стоит вынести в API;
• какие системы можно оставить;
• где возникает дублирование;
• как связать Web, CRM, ERP, Payments, Analytics и AI;
• как подготовить продукт к новым интерфейсам.

На выходе — архитектурная карта без лишней сложности: что должно остаться в frontend, что перенести в backend и какие контракты нужны между системами. Пришлите описание продукта — поможем построить архитектуру, в которой сайт не становится тупиком для дальнейшего развития.