Question

We have a multi-tenant system with multiple different levels of access–sometimes even for the same user as they switch between multiple roles. We’re beginning a discussion on moving over to a RESTful implementation of things. I’m just starting to get my feet wet with the whole REST thing.

So how do I go about limiting access to the correct records when they access a resource, particularly when taking caching into consideration? If user A access example.com/employees they would receive a different response than user B; user A may even receive a different response as he switches to a different role. To help facilitate caching, should the id of the role be somehow incorporated into the uri? Maybe something like example.com/employees/123 (which violates the rules of REST), or as some sort of subordinate resource like example.com/employees/role/123 (which seems silly, since role/### is going to be appended to URIs all over the place). I can help but think I’m missing something here.

edited to mention multi-tenancy

Answer 1

Having the user credentials act as an out of band resource identifier (ie. presenting different views on the same URL to different roles) will turn nasty down the road. Users and applications exchange URLs between them, things turn sour when that happens and the URL simply returns different content for different credentials.

I would say that each role has a different view of the world, therefore each role should access a different path to the service:

• admins connect to example.com/admin/employees
• users connect to example.com/users/employees
• role foo probably connects to example.com/foo/employees

This way you separate the ‘this role sees the world as such and such’ part from the ‘this view of the world is accessible to role foo’ part. An admin can connect to example.com/users/employees and verify how an ordinary user sees the world, w/o the admin having to impersonate a lower privileged alias first.

You can also use the DNS part for same purpose: admin.example.com/employees vs. users.example.com/employees. This is specially viable for a related scenario, when the ‘role’ is not a security role but a multi-tenant namespace (ie. each service provisioned account gets its own ‘view’ of the service).