Q: What is a RESTful approach to linking one resource to multiple different resources? I am working on a small project which consists of a number of resources, including a Person, a Group and a Task. Each Group consists of multiple Person resources. Additionally, each Person can have multiple links to Task, and each Group can have multiple links to Task as well. In somewhat more technical terms, this situation could be described as follows:

*

*there's a one-to-many relationship between Group and Person

*there's a one-to-many relationship between Person and Task

*there's a one-to-many relationship between Group and Task
To nobody's surprise, each of these relationships are also a requirement for RESTful endpoints. In other words, there should be a way to list people in a group, to add people to a group, to add tasks to people/groups, etc.
The relationship between Group and Person is fairly standard in RESTful terms. Something like /groups/{group}/people should do fine, with different HTTP verbs dictating what action should be taken.
Where I'm struggling to come up with a satisfactory solution are the relationships between a Person and a Task, and a Group and a Task. In the context of the project I'm working on, a task is a task and the differences between individual tasks and group tasks are minimal. I suppose that's why I'm struggling to decide which approach would be better in this case.
What I've done so far is completely separate the routes for individual tasks and group tasks. In other words, the project has the following routes:

*

*/people/{person}/tasks

*/groups/{group}tasks
I think those routes make sense. What I dislike about them is the code that they lead to. It's lead me to two almost identical controllers and a few other almost identical files used for validation and what not.
Now, something else I've wanted to explore is using one route to create tasks for both people and groups. Something like /tasks would work fine in that case. The difference between this approach and the first approach I explored is where the "link" is coming from - the first approach has the URL specify if it's an individual task or a group task, and the second approach would receive that information in the request body (e.g. either a person_id or group_id would have to be set, but not both at the same time). What this means is that the second approach requires one controller, but with additional logic to "route" between people and groups.
If I'm being completely honest, I'm probably overthinking this. But this is something that I've had on my mind for a while now and could never figure out which is "more RESTful." I'm curious to hear what other people think and thankful for everyone's two cents.

A: I would just make a class from the reusable part and include it to the Controllers. Afaik. PHP is object oriented, so you can do it with it. Another way of having a single Task class with an assignedTo property and set a Person or a Group there or if PHP is strongly typed then some sort of interface e.g. iAssignable to both. Another way is inheritance or composition with the common part of PersonTask and GroupTask if the difference is more than the upper. So this is rather an OOP problem of code reusage and not a REST problem as far as I understand.
