Fair warning: I am a newbie to REST as well.
Some general remarks, taken from RESTful Web Services by Leonard Richardson and Sam Ruby:
- use plural for your resource names
- use POST to the resource name if the server controls the identity of the resource
- use PUT to the resource/:id if the client controls the identity of the resource
Applying that to your situation I can see the following resources
- /users : list of users
- /users/{id} : specific user
- /users/{id}/tags : list of tags used by this specific user
- /users/{id}/posts : list of posts liked by this specific user
- /users/{id}/follows : list of users that this specific user is following
To add a post to the ones liked by a user, I would POST to /users/{id}/posts
with the identification of the post(s) that are to be added to the list of liked posts in the request body.
Similary to record that user 1 is now also following user 200 and 300, I'd POST to /users/{id}/follows
with the identifications of those users in the request body.
After all you are not supplying the identification of the relationship between user 1 and the other two users, but you are adding two new relationship resources that have user 200 and user 300 as their "follows user" attribute respectively.
A database backing your app would most likely have a Users table, a Posts table and a Likes where the Likes table is the one being added to when you record that a User likes a Post. And the identification of the Likes record will not be the User's identification nor the Post's identification, but it will have its own identification (separate or as a combination of the User's and Post's identifications).
Even if you were to store the Posts liked by a User in something other than a relational model, possibly even without separate identifications for the Likes', the identification of each Likes would still be the combination of the User and the Post.