API Gateway, который переписывает JSON на лету, спасает от зоопарка интеграций

API Gateway, который переписывает JSON на лету, спасает от зоопарка интеграций

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

Типовая схема: входящий webhook → gateway → mapping rules → backend. На выходе можно переименовать поля, вложить данные в нужный объект, проставить дефолты, удалить мусор и прокинуть метаданные. Например:
{"orderId":"123","customer":{"email":"a@b.com"},"meta":{"source":"shop"}}
Из такого легко собрать:
{"id":"123","email":"a@b.com","origin":"shop"}

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

Для сложных кейсов лучше держать трансформацию в отдельном сервисе или Lua/JS-слое у gateway, а не размазывать по микросервисам. Тогда ретрай-политика решает всё: если преобразование не прошло, запрос не уходит дальше, а клиент получает честную ошибку. Идемпотентность — это не роскошь, а база.

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