Стоит ли разделять API на два если создаваемые объекты имеют много схожих полей, но некоторые отличаются

Я хочу создать программу которая будет создавать два типа объектов AWS и GCP. Эти объекты будут иметь много схожих полей, но некоторые поля будут отличаться. Как лучше сделать два разных API под каждый тип объекта или все же одно API так как логический смысл объектов один и тот же?

С одной стороны (вариант 1) лучше разделить API так как:

• будет соблюдаться принцип single responsability
• легче описать схему для валидации так как мы четко знаем какой объект мы хотим получить
• в будущем будет легче расширять если добавится например еще Azure.

С другой стороны (вариант 2) лучше объединить API:

• В будущем это API будет общедоступным. Чтобы пользователю не выбирать между несколькими API (AWS, GCP, Azure) он использует одно.

У второго варианта много недостатков например:

• чтобы описать схему для валидации мы должны включить в нее специфичные поля относящиеся только к конкретному объекту. Например aws_field_1, gcp_field_2. То есть чем больше типов объектов (AWS, GCP...) тем больше схемы будет становиться

Если говорить о принципах и чистоте кода то я выбрал бы вариант один, но если говорить о том что API будет общедоступно и им будут пользоваться много людей, то выбрал бы вариант 2.

Кто сталкивался с таким? Поделитесь опытом как лучше это реализовать.