How RESTful is using subdomains as resource identifiers?

Question

We have a single-page app (AngularJs) which interacts with the backend using REST API. The app allows each user to see information about the company the user works at, but not any other company's data. Our current REST API looks like this:

domain.com/companies/123
domain.com/companies/123/employees
domain.com/employees/987

NOTE: All ids are GUIDs, hence the last end-point doesn't have company id, just the employee id.

We recently started working on enforcing the requirement of each user having access to information related exclusively the company where the user works. This means that on the backend we need to track who the logged in user is (which is simple auth problem) as well as determining the company whose information is being accessed. The latter is not easy to determine from our REST API calls, because some of them do not include company id, such as the last one shown above.

We decided that instead of tracking company ID in the UI and sending it with each request, we would put it in the subdomain. So, assuming that ACME company has id=123 our API would change as follows:

acme.domain.com
acme.domain.com/employees
acme.domain.com/employees/987

This makes identifying the company very easy on the backend and requires minor changes to REST calls from our single-page app. However, my concern is that it breaks the RESTfulness of our API. This may also introduce some CORS problems, but I don't have a use case for it now.

I would like to hear your thoughts on this and how you dealt with this problem in the past.

Thanks!

Answer 1

In a similar application, we did put the 'company id' into the path (every company-specific path), not as a subdomain.

I wouldn't care a jot about whether some terminology enthusiast thought my design was "RESTful " or not, but I can see several disadvantages to using domains, mostly stemming from the fact that the world tends to assume that the domain identifies "the server", and the path is how you find an item on that server. There will be a certain amount of extra stuff you'll have to deal with with multiple domains which you wouldn't with paths:

• HTTPS - you'd need a wildcard certificate instead of a simple one
• DNS - you're either going to have wildcard DNS entries, or your application management is now going to involve DNS management
• All the CORS stuff which you mention - may or may not be a headache in your specific application - anything which is making 'same domain' assumptions about security policy is going to be affected.

Of course, if you want lots of isolation between companies, and effectively you would be as happy running a separate server for each company, then it's not a bad design. I can't see it's more or less RESTful, as that's just a matter of viewpoint.