The first API is intended to support the ability to manage certain types of objects. Generally speaking, you can divide the data within an application into two groups, data that infrequently changes, and well everything else. This initial API is intended to support CRUD operations against objects that seldom change. Within the context of an ecommerce application, entities such as Product categories, clothing sizes, product colors, order statuses, etc. would be classified as seldom changing, making them prime candidates to be managed by this moule.
Infrequently changing data typically is administrated by a small group of internal users, with restrictive permissions. This data often appears in the front ends in drop downs. The following items will fall under the scope of this module.
When we take a look at the resulting structures between the two stacks, for the most part they mirror eah other.
Let's take a look at the resulting controllers. Note that they are inherintly lean. I hold a strong opinion that controllers should be effectively as minimal as possible, leaving additional logic to be located in the service tier. I had posted in the past about this approach which you can find at the following link for a quick read: https://www.matthewdalby.dev/articles/api-design/designing-controllers.