API Gateway не должен “понимать” бизнес. Он должен аккуратно резать JSON

API Gateway не должен “понимать” бизнес. Он должен аккуратно резать JSON

На входе почти всегда грязь: лишние поля, кривые типы, пустые массивы, вложенность как у матрёшки. Если гнать это дальше без нормализации, хендлеры начинают жить в режиме «смотрим в тело запроса и молимся». На шлюзе полезно делать только детерминированные вещи: переименование ключей, вырезание мусора, подстановку дефолтов, разворот вложенных объектов в плоскую схему.

Минимальный паттерн:
• проверили Content-Type и схему;
• привели типы к ожидаемым;
• добавили correlation_id и source;
• отфильтровали поля, которые downstream не должен видеть;
• если payload невалиден — сразу 4xx, без “авось потом разберём”. Идемпотентность — это не роскошь, а база.

Пример маппинга на gateway: входной JSON с user.id, user.email и meta.trace превращаем в тело для очереди или внутреннего API. Снаружи:
{
"user": {"id": "42", "email": "a@b.io"},
"meta": {"trace": "abc"}
}
Внутри:
{
"customer_id": 42,
"contact": "a@b.io",
"trace_id": "abc",
"source": "gateway"
}
Прокидываем стейт через метаданные, а не тащим весь мусор дальше.

Главная ошибка — пытаться в gateway делать сложную бизнес-логику. Его задача: валидация, трансформация, auth, rate limit, быстрый отказ. Всё остальное уходит в очередь или в отдельный сервис. Ретрай-политика решает всё: если downstream лег, шлюз не должен героически переписывать мир, он должен сохранить событие и отдать 202/503 по контракту.

Если трансформируете JSON на лету, держите правило: шлюз — это санитарный фильтр, а не оркестратор. Сначала нормализуем, потом квитируем, и только потом пускаем событие в пайплайн.