Best practise for managing m:n relations in an RESTful API - rest

Question

I'm designing an API and I want to heed RESTful approaches.
Because in my research most similar articles refered to players and teams I'll stick to it.
In this case a player can have more than a team at a time but has to have at least one.
You cannot delete a player if the player ist attached to more than one team.
For that if you want to create a player you need to:
POST /teams/{id}/players
A direct
POST /players
wouldn't take into account that the player has a team so it is not allowed.
If you want to delete a Player you could do:
DELETE /players/{id}
This should only be possible if the player is only attached to one team, but should be refused if the player is in more than one team (for that case you need to dissolve all links to teams except one).
Now I've different approaches to handle creating and removing new Links between Teams and Players:
POST /teams/{id}/players/{id}
PUT /teams/{id}/players/{id}
POST /players-teams (with players_id and teams_id in body)
a. DELETE /teams/{id}/players/{id}
b. DELETE /players-teams/{id}
Some thoughts at the different solutions:
ad 1. GET wouldn't reference the same information
ad 2. I don't provide the id of the relation...
ad 3. should I provide GET /teams/{id}/players-teams and GET /players/{id}/players-teams - or GET /players/{id}/teams-players
ad a. Wouldn't that delete the player?
ad b. who would know the id of the relation?

Answer 1

Given that a player can exist in multiple teams, and the team-player relationship might change, I think it's common to have 2 separate namespaces for this:
players/ <- list of all players
players/{id} <- a single player
teams/ <- list of all teams
teams/{id} <- a single team
The thing that's missing from this is the relationship between team and player. A good way to handle this might be to have players represented as links on the team. A fictional representation of such a team resource:
{
name: "team awesome",
_links: {
self : { href: "/teams/A" },
players: [
{ href: "/players/1" },
{ href: "/players/2" },
]
}
}
If relationships are represented as links on the team resource, the act of removing or adding players to a team is the same as sending a PUT resource to the team and adding/remove these links. The above format uses HAL.
But what if you want to just get a full list of players + their information? It's definitely possible to represent 'all players on a team' as a separate resource, maybe on:
/teams/{id}/players
I would still make sure that all the players in this resource link to /players/{id} and not /team/{id}/players/{id}.
Even though it's not disallowed for a single entity to appear on multiple urls in the system, this might get confusing for a user because it might look like they are separate resources.