API Gateway не должен «понимать бизнес» — он должен безопасно кроить JSON на лету

API Gateway не должен «понимать бизнес» — он должен безопасно кроить JSON на лету

Когда внешний сервис шлёт полезную нагрузку в чужом формате, не тащите это в хендлер. Нормальный паттерн: gateway принимает сырой webhook, валидирует подпись, кладёт request_id и tenant в метаданные, а потом делает тонкую трансформацию тела. На входе: {"id":"123","amount":"10.50","currency":"USD"}. На выходе: {"order_id":"123","total":{"value":"10.50","ccy":"USD"}}. Смотрим в тело запроса, а не в фантазии интегратора.

Правило одно: трансформация должна быть детерминированной. Без запросов в БД, без внешних HTTP-вызовов, без «если поле пустое — догадаемся». Идемпотентность — это не роскошь, а база: один и тот же input должен давать один и тот же output. Иначе ретраи превратят шлюз в генератор фантомных событий. Если поле отсутствует — либо дефолт, либо 4xx, но не магия.

Где это живёт: Nginx + Lua, Kong-плагины, Envoy ext_proc, AWS API Gateway mapping templates, или отдельный трансформер перед очередью. Если формат сложный, лучше вынести логику в отдельный сервис и отдавать в очередь уже нормализованный JSON. Тогда gateway остаётся тупым, быстрым и предсказуемым. Ретрай-политика решает всё: сначала отбей 5xx, потом уже думай о маршрутизации.

Прокидывайте стейт через метаданные, версионируйте схему тела и логируйте исходный payload отдельно от нормализованного. Тогда при кривом вебхуке вы быстро увидите, кто сломал контракт, а не будете ловить 5xx на ровном месте.