基于用户查看权限的不同REST资源内容

时间:2012-06-12 12:07:04

标签: web-services api rest restful-architecture access-rights

我希望根据访问权限为不同的用户提供相同问题的不同答案。我读到了这个问题:

Excluding private data in RESTful response

但我不同意接受的答案,该答案指出您应该同时提供/people.xml/unauthenticated/people.xml,因为我对REST的理解是特定资源应该存在于特定位置,不是几个,取决于你感兴趣的信息量。

我正在设计的系统比那个更复杂。假设用户创建了许多朋友圈,并为他们分配了不同的访问权限。例如,我的“熟人”圈可能可以访问我的生日,而我的“专业”圈子可能可以访问我的工作经历,但不是相反。为了应用我提到的问题的答案,我需要有一种方法来获取所有用户的圈子(出于安全原因我可能想保密),然后通过/circles/a/users/42,{{ 1}},/circles/b/users/42等等,然后合并结果以显示可用的最大信息量。 显然,没有一个圆圈可以获得其他任何圈子获得的所有信息。我认为这很棘手(请注意,我可能需要对几种对象和未来做这件事)版本可能需要不同的程序),但如果我想对特定用户强加安全限制尽管他也在我的某些圈子中?这个问题甚至可以解决吗?即使我拒绝回复任何上述问题并提出一个可以给我答案的新查询,它仍然会揭示这样一个事实,即由于个人访问限制,这个特定用户的处理方式不同。

我在这里缺少什么?我甚至可以开发RESTful Web服务吗?

如果结论是行为不是RESTful,那么这仍然会构成违反REST合同在道德上可行的情况吗?如果是这样,有什么负面影响?我冒险代理缓存问题吗?

2 个答案:

答案 0 :(得分:27)

根据菲尔丁的论文(这真是一篇很棒的文章):

  

资源是对一组实体的概念映射,而不是与任何特定时间点的映射相对应的实体。

换句话说,如果您有一个被定义为“请求用户的已分配项目”的资源及其/projects URI可访问的表示,则您不会通过返回一个REST列表来违反REST的任何约束。用户A的项目(即表示)和用户B获取相同URI时的另一个(表示)。通过这种方式,界面是统一/一致的。

除此之外,REST仅规定响应中包含显式缓存指令,无论是“长时间缓存”还是“根本不缓存”:

  

缓存约束要求将对请求的响应中的数据隐式或显式标记为可缓存或不可缓存。

您选择如何管理由您决定。

牢记这一点,

只要您没有违反统一界面的限制,您应该放心返回资源的表示,这取决于请求表示特定资源的用户 - 不要不使用单个资源标识符来返回不同资源的表示。

如果有帮助,请考虑服务器也会响应资源的不同表示形式 - XML或JSON,法语或英语等。随请求一起发送的凭据只是服务器在确定时可以使用的另一个因素哪个表示要发送回应。 这就是标题部分的用途。

答案 1 :(得分:1)

我同意其他解决方案似乎不对。它使URL结构变得复杂并且更难以找到资源。但是,如果您正确地执行了REST,那么资源的URL是什么并不重要,因为服务器控制它(并且可以根据需要自由地重新定位它)。如果您的客户端确实是“REST”,它将通过事先与服务器协商发现它所需的资源。所以这条路在客户端真的无关紧要。我不喜欢它,因为它使用起来很混乱 - 不是因为某些违反REST原则的行为。

但这可能无法回答你的问题 - 你没有提到的是你的安全设置 - 可能你是一个会话令牌,请求作为请求标题的一部分。因此,您的后端处理应该能够将其与特定的安全约束相关联。从那里,您可以使用您需要的任何业务逻辑形成列表,并根据与会话相关的用户安全性返回有限的资源。

对于算法本身,通常会实现最小或最严格的类型算法,将允许的数据合并到响应中(非常类似于java领域或Microsoft的用户安全模型)。

如果对于受限制/非受限制的情况,数据的结构不同,您可以创建两种不同的数据表示形式,并返回用户有权查看的数据。无论如何,客户端应该询问接受的mime响应类型,并且它将根据请求头中的会话安全性提供不同的答案。或者,您可以提供带有表示的可选元素,并根据授权填写适当的一个基础(尽管在我看来这是一个小小的黑客)。

相关问题