• charlesembling

Should Role Based Access Control (RBAC) Influence how you define your API Routes?


I'm currently implementing RBAC in an application for a client that has some complex roles and permissions and although there are some great articles on how to add RBAC with some nice examples (, I didn't find anything that explicitly mentioned this, and I couldn't stop my brain from asking this question:

Should Your API Routes/Endpoints be heavily influenced by RBAC rules, meaning the RBAC rule(s) sit on top of the API endpoint, or Should API Endpoints NOT be influenced by RBAC, and the service layer within the API endpoint should be concerned with RBAC? Let's assume that API Endpoints Should be Organized in a Restful-RBAC manner, meaning they should be RESTful and recommended to deviate and "spread" endpoints out when RBAC rules demand it. Example: You are faced with a real world example where RBAC rules exist that are user type specific, meaning, one permission granted by a role allows a logged in user to see "client" users and another permissions grants the logged in user to see "employee" users. Because of these RBAC demands, the API Endpoints should be adjusted in the following way: Instead of this: GET /Projects/{guid}/Users POST /Projects/{guid}/Users GET /Projects/{guid}/Users/{guid}

PUT /Projects/{guid}/Users/{guid}

DELETE /Projects/{guid}/Users/{guid}

Do this: GET /Projects/{guid}/EmployeeUsers POST /Projects/{guid}/EmployeeUsers GET /Projects/{guid}/EmployeeUsers/{guid} PUT /Projects/{guid}/EmployeeUsers/{guid} DELETE /Projects/{guid}/EmployeeUsers/{guid} GET /Projects/{guid}/ClientUsers POST /Projects/{guid}/ClientUsers GET /Projects/{guid}/ClientUsers/{guid} PUT /Projects/{guid}/ClientUsers/{guid} DELETE /Projects/{guid}/ClientUsers/{guid} Why? PROS "Spreading" the endpoints in a way influenced by RBAC allows ProjectRole Permission attributes to sit on top of the endpoint, making permissions a LOT easier to: Develop - RBAC rules translate easily into API endpoint management. There may be some exceptions for very complex RBAC, but these would be infrequent. Maintain - Simpler is always easier to maintain. Communicate (by this very nature, the UI has to adjust as well, which creates the side effect of strengthening the UI's understanding of RBAC. Test - The Use Cases are much simpler and have less (if then logic checks); There may be more unit tests, but simpler is always better.


RBAC rules need to known up front,

Changes to RBAC rules cause "busy" work, because when routes change, maintaining synchronization of API & UI gets harder

Question: Should RBAC (Role Based Access Control) Influence your API Routes?

Answer: It Depends

WHEN TO RECOMMEND Go this route only when you know the RBAC rules up front, before development occurs, and they are not likely to change. Changes to RBAC after development could produce maintenance headaches for the API & UI. However, the the headache is just figuring out how to go from "current state" to "ideal state", and once "ideal state" and and the migration path to get there is identified, maintaining endpoints influenced by the new RBAC rules could still be assumed to be more favorable given the WHYs. WHEN TO AVOID Since RBAC is heavily influencing, almost "dictacting", your API organization, drastic changes involving RBAC will cause organization headaches. If you anticipate RBAC is going to change dramatically and you have to adjust, maybe RESTful is better and implementing RBAC inside the endpoint is better. If it's a public API or one accessed by many clients, it could be harder to make route changes and the emphasis may instead be on maintaining RESTful and embedding RBAC deeper down into the service layer.

  • LinkedIn Social Icon
  • Vimeo Social Icon
  • Twitter Clean