Из того, что я исследую, не рекомендуется создавать составной API, если используется API-шлюз, но составление должно происходить в самом API-шлюзе.
Не могли бы вы сослаться, где вы нашли утверждение?
ИМХО состав службы не является задачей шлюза API. Это задача n уровня интеграции (вам не нужно иметь отдельный продукт или услугу esb, под уровнем интеграции вы можете понимать любые сервисы или уровень сервисов, реализующие такие возможности, как состав, преобразование и т. Д.)
Вы не указали какой-либо продукт или услугу API, это зависит от продукта, способен ли он выполнять какую-либо логику или нет (некоторые делают, некоторые нет). Даже если продукт API-шлюза способен выполнять любую логику, на самом деле я тоже не рекомендую его (вам придется бороться с обслуживанием, обработкой ошибок и обработкой состояний, ..)
Но если мне нужно сделать композицию в API-шлюзе, разве это не значит, что мне нужно представить там некоторую доменную логику
(лично я не чувствую себя комфортно, делая это), потому что мне нужно составить содержательный запросный контракт и, возможно, последовательность вызова API?
что вы подразумеваете под composition in API gateway? Я предполагаю под термином выполнение некоторой логики. Тогда логика скрыта от клиентов API.
Или это может быть слой композитного API звучит лучше?
Действительно.
Обычно стараются трактовать API-шлюз как интеллектуальный прокси-сервер (выполняет авторизацию, регулирование, клиентское API-хранилище и т. Д.), Но открытые серверные службы должны быть уже открыты, поскольку они