__“Don't build elaborate APIs that mimic the back-end system's design. Instead, build consumer-driven APIs that provide the service in a format that the front-ends prefer.”__ (с) Gregor Hohpe, Cloud Strategy При проектировании API учитывайте контекст, в котором сущность используется. Вместо всеобъемлющего `GET /product/123` Используйте хотя бы контексты `GET /catalog/product/123` `GET /checkout/product/123` `GET /`someothercontext`/product/123` С теми атрибутами, которые нужны в заданном контексте. Эту рекомендацию можно использовать и в монолите, в микросервисах же она жизненно-необходима. Если пойти дальше, в DDD (например через event storming), то API изменятся еще сильнее и станут отражать поведение, а не сущности: /GetAvailableProducts /GetProductDeliveryOptions /GetProductsAtSale Такие API удобно развивать, они обеспечивать минимальную связанность и максимальное сцепление. Проверим от противного Три Use Cases: - Отобразить доступные на складе продукты - Отобразить варианты доставки продукта - Получить список продуктов, участвующих в распродажах В случае реализации трех сценариев с использованием метода /product/123 мы получаем зависимость всех трёх от одного API. Потребность в изменениях для одного приведет к необходимости координации изменений со всеми остальными. В случае API, определяемых от поведения таких зависимостей нет.