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 item
GET /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.