REST API - One operation that belongs to two different resource endpoints - ruby-on-rails

Question

I find myself too many times in front of a situation when I should create two different resources on an API server, that are initiated by one single action. I would call it cross-controller opertaion: an operation that requires logic to be performed in two different controllers
For example, imagine an applicaiton with a User model and an Account model
User can be associated to multiple accounts.
In my REST API I have an /accounts/ endpoint and a /users/ endpoint which are responsible for the Account and User model respectively, and /accounts/:account_id/users endpoint for the assocation between these 2 models
So if a user choose to disassociate itself from an account I make such a request: HTTP DELETE /accounts/:account_id/users/:id
When a user registers I obiously POST /users/ to create a new user
There is also an option for a user to register and get directly associated to an account (by a special invitaion for example). In such case I would have to register a user and create an association to the account being invited to, preferably doing that in a single request to the server.
I know I can do a request to /users/ in order to create the user and then another request to /accounts/1/users/1 to create the link between the user and the account, but doing so only to stick to the REST principles seems redundant.
Another option is to create a different action such as register_from_invitation that will take care of both action but then the question is where it should sit. In the AccountUsers controller, in the Users controller or in the Accounts controller. This also seems wrong to me.
Any prefered way to solve such a design issue?

Answer 1

I can see several possible solutions.
The method that you described (making to requests: first to /users and second to /accounts/...) is the most REST-full. It is simple, logical and used widely. It may look a little awkward, but it's not. Here you split your logic strictly, not mixing up methods from two controllers.
Then, you can always accept requests to POST /accounts/:account_id/users/. And here create a new user and bind it to the account. From the outer space of your app it looks good, but inside it will cause a slight mix of User and Account methods in Account controller. That's no good.
If you still want to have register_by_invitation method, you can confidently put it in Users controller. Create user there and bind it to some Account you receive in request params.
However, if you want to keep your app RESTfull and do not want to mix the logic from several controllers into one, there's only one I see.

Answer 2

Consider adding another resource called UserAccountMembership. The benefit of this is that you'll separate responsibilities: User and Account resources will remain clean, and at the same time you'll get a resource where you expose specific information about a "connection" between those two (like date/time of a link creation, active/inactive status etc.):
/useraccountmemberships/{useraccountmembershipid} POST, PUT, GET, DELETE
{
"Id": useraccountmembershipid,
"UserId": userid,
"AccountId": accountid,
"Timestamp": "2018-1-1",
...
}
You may still want to allow access to memberships via a parent resource, which is fine:
/users/{userid}/useraccountmemberships GET
/accounts/{accountid}/useraccountmemberships GET