Проводит ли арендатор в пользовательский HTTP-заголовок RESTful?

Я рассматриваю следующие два способа идентификации арендатора HTTP-запроса в среде с несколькими арендаторами - жесткое кодирование арендатора в URI:

/{tenantUuid}/foos/{id}

Или передать арендатора в пользовательский заголовок HTTP, например:

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

(аналогично: http://docs.openstack.org/api/quick-start/content/)

Обратите внимание, что {id} является уникальным для всех арендаторов, поэтому /{tenantUuid}/foos/{id} все равно однозначно идентифицирует ресурс foo.

Мой вопрос: теоретически ли это правильно использовать пользовательский заголовок, или использование пользовательского заголовка не является успокоительным. Я также знаю, что заголовки X-... устарели, но вопрос игнорирует этот факт.

Спасибо.

Ответ 1

URI должен однозначно идентифицировать ресурс.

Но это ортогонально авторизации и доступу. Два человека могут попросить один и тот же ресурс. Никто не получает ничего, проверенную копию или ошибку; тогда как другой получит все это, потому что они правильно определены в заголовке авторизации.

Теперь URI может включать идентификатор арендатора как часть своего уникального URI, в этом нет ничего плохого. Но в любом случае сам ресурс (каким-либо образом, в том числе посредством компонента его URI или внутреннего состояния) "узнает", к какому арендатору он принадлежит.

Итак, в вашем случае вы должны использовать заголовок HTTP Authorization для правильной идентификации запрашивающей стороны, а затем использовать эту информацию для внутреннего определения, будет ли и каков будет ответ на конкретный запрос. Запрашивающий может быть уполномочен видеть ни одного, одного, нескольких или всех арендаторов в системе.

Для этого случая использования вам вообще не нужен настраиваемый заголовок.

Ответ 2

Если вам нужен идентификатор арендатора, чтобы идентифицировать ресурс, тогда путь RESTful должен был иметь его в URL-адресе. Если вы этого не сделаете (идентификатор уникален для всех арендаторов), то технически вам это не нужно в URL-адресе или заголовке.

Так как id уникален для всех арендаторов, то /foos/ {id} может однозначно идентифицировать этот ресурс и является RESTful.

Я бы не использовал пользовательские заголовки как способ обращения к ресурсу. Они должны использоваться вместо этого, чтобы передавать вспомогательную информацию типа accept, токены auth и т.д. Вам нужно решить, важно ли определить ресурс и поместить его в URL-адрес или нет.

Ответ 3

Для вашего приложения может быть так же интересно отделить пользователей от разных арендаторов, как от приложения, такого как список Craig, чтобы отделить его от городов.

Но вы хотите показать все виды разделов в вашем URI? Вы хотите URI, например /comcast/blackeyes/long-haired/london/?

Быть RESTful или RESTenough не ответит на этот вопрос. Это просто вопрос вкуса.