JRLambert JRLambert - 4 days ago 5
reST (reStructuredText) Question

Similar Endpoints on multiple API's

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?

Answer

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
Comments