Say I have a few API's set up as micro-services. One API is to manage users (user API) and looks like:
/users GET, POST
/{id} GET, PUT, DELETE
Then there is another API that is used to manage security information (access roles, permissions, etc.), and a user created in the user API can be assigned a group that is defined in the security API. Should that association be made in the security micro-service, or in the user micro-service?
My initial thought is in the security micro-service since that is where all applications will request the security information from. With that, and that a user can only be assigned to one group, I then come up with the endpoint of:
/users/{id}/group GET, POST, DELETE
But that endpoint feels like it belongs more in the user micro-service. The other endpoints that are an option are:
/groups/{id}/users GET, POST, DELETE
/{id} GET, DELETE
But that then makes it seem that a user could be assigned to multiple groups. However, I could design it so that when a user is associated to a group, it disassociates it from a group that it was previously associated with.
What is the best option, or is there a better way to handle these types of api calls that I am not aware of?
I guess there is no 'right' way necessarily. Here is how I would approach it.
Based on :
However, I could design it so that when a user is associated to a group, it disassociates it from a group that it was previously associated with.
/groups/{id}/users GET, POST, DELETE
/{id} GET, DELETE
This endpoint would cause some issues in that the Id would change and you would therefore have to change the url you call after a user switches to a different group. So consecutive calls need to go to a new endpoint.
For example : /groups/1/users/1 could be valid one moment, but when the user moves groups /groups/1/users/1 will no longer return a result. It would now become /groups/2/users/1
Whereas with:
/users/{id}/group GET, POST, DELETE
The endpoint won't change if the user switches groups, which keeps it cleaner and clearer in my opinion. The user is still the same and it's clear that the group is associated with this user, but it doesn't matter what group is being referred to as it will always return the associated group for the user with that id
I guess the bottom line is that the endpoint should reflect what you are trying to achieve, if you are getting the group for a user :
/users/{id}/group GET, POST, DELETE
or if you are getting all users for a group:
/groups/{id}/users GET, POST, DELETE