DTO design considerations for nested collections - api

Question

Given that I have a model denoting a city which holds a collection of streets.
public class City {
public int Id { get; set; }
public string Name { get; set; }
public IEnumerable<Street> Streets { get; }
}
public class Street {
public int Id { get; }
public string Name { get; }
public IEnumerable<Building> Buildings { get; }
}
If a client is interested in all cities (api/cities/all) and I'd return him the full collection, this would lead to a massive response, depending on the size of the dataset. So I thought first about returning only street ids inside the streets collection. This however feels awkward because while the ids might be useful to further fetch the streets, they hold no meaningful value for a client (it doesn't make sense to populate a list of ids on a view in order to show what streets are in a city, doesn't it?).
My next idea was to ditch the streets collection completely and instead offer an API endpoint to fetch the streets of a city:
api/cities/3737/streets
That way I can fetch a complete list of streets, however the returned data then doesn't contain any information to where the streets belong to. If I a client now wants to show both the streets and the city, he'd have to make 2 API calls to get the information he needs.
What is a common way to return such data?

Answer 1

I would create 2 city objects, a city object containing only the basic data(like ID & Name) and a cityDetail object containing all the data (including the full street plan).
Depending on your situation you might repeat this pattern for the buildings.
You can then return the city object in your list call and only if a get by id is performed you would return the cityDetail object.
The bad => your api is sorta "inconsistent" as the city objects you get via a list are not the same as the ones you get via the get. You could make 2 resources: city & cityDetail with cityDetail not having a List function and city not having a getByID function but still it's not as clean & predictable as a single resource.
The good => Performance wise & usage wise this usually is a perfect match. You will never show a list of cities with streets so the city object would be sufficient. When you are viewing a single city it is very likely you want to show all data including streets(or at least use this data on that page) so the cityDetail object would fit here as well.
Performance wise it's kinda obvious that fetching 1 milion streets for a getAllMyCities call is overkill ;)