Is it good design to have a controller for each object of your API?  I know this is a short question, but it's really a fundamental question that I do not know.  Say I have a school or a CRM.  That is a lot of controllers.  I don't know another way to do it, but it feels like a DRY problem.I am using ASPNET Core if that matters.EDIT:  By object I meant the actual classes in my project.  But the answers have cleaned that up.  I was thinking about it as a sole one-to-one correspondence.
If I have ten objects, should there be ten controllers for a Web API?
api design;asp.net mvc web api
Define 'object'You have one controller for each resource. Where a resource is a thing that your API provides (user, customer, student, sports-team, etc.)Resources don't necessarily map one-to-one to domain objects. Sometimes a resource is made up of several domain objects and sometimes several resources reference the same domain objects.A controller may return several representations of the same resource, depending on how it's called. Generally it's only two though. A summary of the resource when returning a list:GET /students[    { id: 1, name: john smith },    { id: 2, name: jane smythe }]And a detailed representation when getting a specific itemGET /students/1{    id: 1,    name: john smith,    age: 27,    location: Venezuela}If a resource has a strong dependency on a parent resource (e.g. a room cannot exist without the building it's in), I would still have a room controller and handle the dependency via required properties and business logic. (i.e. room must specify building_id)To put the room logic in the building controller is giving it too many responsibilities.