Is passing the tenant in a custom HTTP header RESTful?

Question

I'm considering the following two ways of identifying the tenant of a HTTP request, in a multi-tenant environment - hardcoding the tenant in the URI:

/{tenantUuid}/foos/{id}

Or passing the tenant in a custom HTTP Header, such as:

X-Auth-Token: 7d2f63fd-4dcc-4752-8e9b-1d08f989cc00"

(similar to: http://docs.openstack.org/api/quick-start/content/)

Note that the {id} is unique across all tenants - so /{tenantUuid}/foos/{id} will still uniquely identify a foo Resource.

My question is - is it theoretically correct to use a Custom Header for this, or is the use of a Custom Header not restful. I am also aware that X-... headers have been deprecated, but the question is ignoring that fact.

Thanks.

Answer 1

The URI should uniquely identify the resource.

But this is orthogonal to authorization and access. Two people could ask for the same resource. One gets nothing, an elided copy, or an error; whereas the other would get the whole thing because they are properly identified in the Authorization header.

Now the URI can include the tenant id as part of its unique URI, there's nothing wrong with that. But either way, the resource itself will (somehow, including by a component of its URI or an internal state) "know" to which tenant it belongs.

So, in your case you should be using the HTTP Authorization header to properly identify the requester and then use that information to determine internally whether and what the response will be for a specific request. A requester may be authorized to see none, one, some or all tenants on a system.

You shouldn't need a custom header at all for this use case.

Answer 2

If you needed the tenant ID to identify the resource, then the RESTful way would be to have it in the URL. If you don't (id is unique across tenants) then technically, you don't need it in the URL or the header.

Since id is unique across all tenants then /foos/{id} can uniquely identify that resource and is RESTful.

I would avoid using custom headers as a way of addressing a resource. They should be used instead to pass ancillary information like accept types, auth tokens, etc... You need to decide whether it's critical to identify the resource and put it in the URL or not.