As REST API builder I have faced this problem few times without a good solution:

Having an entity organization it seems clear that we can REST model it as /organization with all the pack (GET, POSt, PUT, DELETE, filtering, paging, ...)

NOTE that I am using Spring with @RestController classes and spring-data PagingAndSortingRepository injected into the controller.

The problem starts with 

/organization/{id}/users

which is a perfect URL for a REST API but starts to cause some pain.

If we follow the path of processing the request in organization controller we will need to add UserDAO to the controller, so we can end with many DAOS injected in every controller, and every controller responsible of returning lots of different objects: organizations, users, models, etc.

Pushing the problem to the DAO layer is not a solution; Trying to make the repositories to return all these different objects will not work (PagingAndSortingRepository shall complain if we try to work with different entities) and it does not feels like the right thing because we force repositories to work with entities out of its domain.

Using a intermediate layer between controllers and DAOs could work, a service layer that can hold those different DAOs and offer a single facade, but again feels wrong: First the controller is still working with many different objects that do not belong its domain, Second we have a layer with no real purpose that can grow with combinations of DAOs, or having a great master DAO object able to query anything.

What is the good way to solve this?