Nested resources and microservices: how to avoid monoliths?

I want to retrieve the address details of a person.

According to the REST specification I would have to have the following path:

GET /person/<person id>/address/<address id>

Now, suppose I want to retrieve the electronic addresses, I would have:

GET /person/<person id>/address/<address id>/electronic/<elec id>

And so on. While REST-wise it is fine, it can lead to a monolithic approach as the openapi generator (but also a person implementing it) would create one lone microservice handling several kind of data.

What could be another way to deal with this scenario? I was thinking of:

1-reversing the logic

GET /addresses/<person id>/<address id>
GET /electronicAddresses/<person id>/<address id>/<electronic address>

2- use headers/query string parameters and leave to single services

GET /addresses/<address id>?person_id=
GET /electronicAddress/<elec id>?person_id

Can I have some practical directions? I feel that inner resource approach would explode in the end...