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

Question

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

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

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

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

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

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

Компромисс между кэшированием, конечно, минимальна, поскольку ресурсы кэшируются только клиентом, а не через посредников, но есть компромисс для видимости тоже (URI содержит (aythenticated) Идентификатор пользователя). Наконец, появилась возможность позволить пользователю 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

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

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

Answer 3

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

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

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

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