RESTful HTTP: отображение разных представлений для двух пользователей на одном и том же URI

Question

Я разрабатываю гипермедиа API, да, RESTful API с ограничением гипертекста.

Каждый пользователь системы будет обращаться к системе, используя свои собственные учетные данные, поэтому каждый обрабатываемый нами запрос проходит проверку подлинности иавторизован.Каждый пользователь, как правило, имеет определенные учетные данные, так что у них могут быть разные права доступа (например, нет, чтение, чтение / запись) для каждой коллекции.

Мы хотим, чтобы клиент был заполнен одним URI, с которого он начинается,это может быть документ служб атома или иерархия (расширения проекта иерархии атомов) коллекций атомов.

Мой вопрос в основном заключается в том, должны ли пользователи видеть разные представления для одного и того же URI или пользователи должны быть направлены на разные URIна основании их разрешений?

Например: у пользователя A и пользователя B разные права в системе.Они входят в систему с разными учетными данными, к тому же начальному URI.Успешный ответ может быть одним из следующих 2:

1. 200 OK, и пользователь A видит что-то отличное от пользователя B на том же URI
2. 302 (или другом перенаправлении) каждого пользователянапример, / endpoint / userA (которой они владеют)

Компромисс между кэшируемостью, конечно, минимален, поскольку ресурсы кэшируются только клиентом, а не посредниками, но есть компромисс для видимости (URI содержит (идентифицированный) идентификатор пользователя).Наконец, есть возможность в будущем разрешить Пользователю A (или суперпользователю) видеть то, что видит Пользователь B.

Я не спрашиваю, что делают Twitter или Facebook, меня больше интересует, что должны делать практикующие REST.скажи об этом.

Answer 1

Лично я считаю, что это действительно сложный вызов, и я думаю, что многое зависит от того, сколько контента изменится. Если разница заключается в пропуске нескольких дополнительных деталей, я бы, вероятно, отнесся к ним как к единому ресурсу, который зависит от пользователя.

Однако, как только различия станут более значительными, я начну создавать разные ресурсы. Я бы все-таки попытался избежать создания ресурсов, специфичных для конкретного пользователя. Возможно, для конкретного ресурса вы можете создать набор подресурсов с различным уровнем содержания. например,

/Customer/123?accesslevel=low
/Customer/123?accesslevel=medium
/Customer/123?accesslevel=high

Этот метод в сочетании с 302 может быть достаточным в некоторых случаях. В более сложных случаях вы можете использовать несколько параметров строки запроса.

/Employee/123?SocialSecurityNo=yes&SalaryInfo=yes

Я не верю, что есть простой ответ на этот вопрос. Я думаю, что ответ похож на большинство хитрых сценариев REST: ваше решение может быть настолько креативным, насколько вы хотите, если вы не нарушаете ограничения: -)

Answer 2

Мой вопрос, в основном, должен ли пользователь видеть разные представления для одного и того же URI, или пользователи должны быть направлены на разные URI на основе на их разрешения?

Например: пользователь A и пользователь B имеют разные разрешения в система. Они входят в систему с разными учетными данными, к тому же начальному URI. Успешный ответ может быть одним из следующих 2:

1. 200 ОК, и пользователь A видит что-то отличное от пользователя B на том же URI
2. 302 (или другое перенаправление) каждого пользователя, например, / конечная точка / пользователь A (который они владеют)

Оба способа ОТДЫХАЮТ. Представление ресурса может зависеть от разрешений. Связь не имеет состояния, потому что вы отправляете учетные данные (имя пользователя, пароль) с http-аутентификацией при каждом запросе. Перенаправление на другой вариант представления после проверки разрешения - отличная идея. Таким образом, вы можете полностью отделить логику авторизации от логики представления ресурса, чтобы вы могли переместить ее даже на другой сервер и создать очень хорошо кэшируемые представления ресурсов. Например, с помощью GET /endpoint/userA вы можете перенаправить userA на /endpoint/userA?owner=true, потому что она является владельцем профиля, или вы можете создать набор функций: /endpoint/userA?feature1=true&feature2=false и т. Д. Очень просто настроить мелкозернистую контроль доступа для этого. Еще один способ сохранить кеширование, если вы добавляете идентификатор пользователя в каждый запрос queryString, но это решение с перенаправлением намного чище. Спасибо за это!

Answer 3

Вариант 1, ответ 200 - приемлемый ответ REST, более удобный для пользователя, чем вариант 2.

API данных Google обеспечивают достойную реализацию REST поверх своих пользовательских служб и реализуют опцию 1. Например, API данных календаря Google позволяет пользователю запрашивать собственный канал человека, выполняя HTTP GET запрос на http://www.google.com/calendar/feeds/default/private/full.