API нужен не для того, чтобы «дать доступ к данным». Он нужен, чтобы одна система могла безопасно положиться на возможность другой

Внутри система может хранить десятки таблиц.

Потребителю обычно нужен один бизнес-объект.

Если наружу отдать внутреннюю модель как есть, любая техническая переработка превращается в breaking change.

Поэтому контракт строится вокруг смысла:

заказ;

клиент;

платёж;

остаток;

заявка;

статус;

документ.

Не вокруг того, как эти сущности сегодня разложены внутри кода.

REST хорошо подходит для работы с ресурсами.

RPC — когда важнее явно выразить операцию.

GraphQL — когда клиенту действительно нужно гибко собирать представление из большого связанного графа данных.

AMPE выбирает интерфейс по характеру взаимодействия, а не по модности подхода.

Если система A не может завершить действие без ответа B, доступность B становится частью доступности A.

Это нормально, если ответ действительно нужен сейчас.

Например:

проверка лимита;

расчёт цены;

авторизация операции.

Но если можно принять запрос и обработать его позже, жёсткий request/response может только увеличить связанность.

AMPE отделяет online-вызовы от процессов, которым больше подходит асинхронная модель.

Транспортный уровень может быть успешным, а бизнес-правило — нет.

Клиент найден, но заблокирован.

Заказ принят, но требует проверки.

Резерв создать нельзя.

Поэтому контракт должен различать:

технический успех;

валидационную ошибку;

бизнес-отказ;

временную недоступность;

неопределённое состояние.

Только тогда consumer понимает, что делать дальше.

Ответ потерялся.

Клиент повторил запрос.

Gateway перезапустил операцию.

Без устойчивого ключа один retry может создать:

второй заказ;

второй платёж;

второй резерв;

вторую заявку.

AMPE проектирует идемпотентность до появления первых дублей, а не после.

Если запрос имеет смысл ждать максимум две секунды, timeout в 30 секунд только блокирует ресурсы.

Если downstream обычно отвечает за три секунды, timeout в 500 мс создаст ложные ошибки.

Мы связываем timeout с общим latency budget и реальной ценностью ответа.

Downstream уже перегружен.

Сто клиентов повторяют запрос.

Каждый повторяет ещё три раза.

Нагрузка становится выше именно в момент, когда система слабее всего.

Поэтому нужны:

backoff;

jitter;

лимит попыток;

circuit breaker;

понимание, какие ошибки вообще можно повторять.

Добавить необязательное поле — обычно не breaking change.

Удалить поле или изменить его смысл — уже другое дело.

AMPE фиксирует compatibility policy и deprecation strategy, чтобы версии не накапливались бесконечно.

Сервис знает, кто к нему пришёл.

Но ещё нужно определить, что этому клиенту разрешено.

Service account, OAuth2, mTLS, signed requests, scopes, roles — конкретный механизм зависит от среды.

Главное — API получает минимально необходимый доступ и понятную trust model.

Нужно видеть:

кто вызвал;

какая операция;

какой correlation ID;

сколько заняло;

какой downstream участвовал;

где возникла ошибка;

какой бизнес-объект затронут.

Тогда интеграционная проблема диагностируется по цепочке, а не по отдельным логам двух команд.

Бизнес-возможность становится API-контрактом.

Контракт получает схему и семантику.

Security определяет доступ.

Timeout, retry и idempotency — поведение при нестабильности.

Versioning — правила изменения.

Observability — контроль реального исполнения.

Так API становится устойчивой границей между системами.

Системы меньше зависят от внутренних моделей друг друга.

Ошибки становятся предсказуемыми.

Повторные запросы не создают повторный эффект.

Изменения API проходят управляемо.

Интеграции легче тестировать и сопровождать.

И главное — API перестаёт быть «окном в приложение» и становится контрактом, на который действительно можно опереться.