REST isn't carved in stone and this many-to-many relationship of nested resources is a very common problem with mostly two possible approaches. Which of the two is best for your specific case would depend on a few details and maybe how exactly asp.net handles things. But I will just describe both and explain why I mostly prefer the second approach.
Approach one would simply use the nested resources approach you already have. Doing
would add Person 123 to list 234. This is simple and easy and you could see this used often enough but has a few disadvantages. (obviously you could mirror this and us
POST /api/Persons/123/Lists/234 instead)
The second alternative is to handle it as a resource of its own named ListPersons (as you maybe already named the table holding the relationship information for this).
To create such a resource:
similar to delete a person from a list or update the relationship. While at first this may seem a bit superficial it is most likely easier to implement and test. Also it keeps the controller actions simpler, since it lets them stay "single responsibility". The main advantage may be that if you later want to add additional data to the relationship adding this information was params will be easy and names can't clash with similar names in the other two tables.
As an example assume a List would be a team and later you decide to add the 'role' the Person (in this case a player) has in this team. You can easily add this like
even if the Person resource has a role (say the preferred role for this Person) by itself.
At least in Rails this has the additional advantage that within the controllers the action names can still reflect the REST verbs, while in approach one since create etc are already taken for the List itself you would have to come up with new names.
For completeness approach three would be to simply update a List with a param that contains a list of Persons. I would totally dislike this for many reasons so I just mention that this too is seen in the wild.