27

我想根据访问权限为不同用户提供对同一问题的不同答案。我读了这个问题：

在 RESTful 响应中排除私有数据

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

我正在设计的系统比那个系统还要复杂。假设用户创建了多个朋友圈，并为他们分配了不同的访问权限。例如，我的“熟人”圈子可能可以访问我的生日，而我的“专业”圈子可能可以访问我的工作经历，但反之则不行。为了应用我提到的问题的答案，我需要有一种方法来获取所有用户的圈子（出于安全原因我可能想保密），然后通过/circles/a/users/42, /circles/b/users/42,/circles/c/users/42等等，然后合并结果以显示最大数量的可用信息。显然，不一定有一个圈子可以获得其他圈子获得的所有信息。我相信这已经够棘手了（请注意，我可能需要对几种对象执行此操作，并且将来的版本可能需要不同的过程），但是如果我想对特定用户施加安全限制，尽管事实上他也是在我的某些圈子里？这个问题还能解决吗？即使我拒绝回答上述任何问题并提出一个可以给我答案的新问题，它仍然会揭示这样一个事实，即由于个人访问限制，该特定用户会受到不同的对待。

我在这里想念什么？我是否有可能开发 RESTful Web 服务？

如果结论是该行为不是 RESTful 的，那么这是否仍然构成违反 REST 合同在道德上可以接受的情况？如果是这样，有什么负面影响？例如，我是否会冒代理缓存问题的风险？

4

2 回答 2

31

根据菲尔丁的论文（这确实是一篇很棒的文章）：

资源是到一组实体的概念映射，而不是在任何特定时间点对应于映射的实体。

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

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

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

您选择如何管理这取决于您。

牢记这一点，

只要您不违反统一接口的约束，您应该可以放心地返回资源的表示，该表示根据用户请求特定资源的表示而变化——不要使用单个资源标识符来返回表示的不同资源。

如果有帮助，请考虑服务器也会以不同的资源表示进行响应——XML 或 JSON、法语或英语等。随请求发送的凭据只是服务器能够用于确定要使用哪种表示的另一个因素发送响应。这就是标题部分的用途。

于 2012-09-21T21:32:49.873 回答
2

我同意其他解决方案似乎不正确。它使 URL 结构复杂且更难找到资源。但是，如果您正确地进行了 REST，那么资源的 URL 是什么就无关紧要了，因为服务器可以控制它（并且可以自由地重新定位它认为合适的位置）。如果您的客户端真的是“REST”，它会通过事先与服务器协商来发现它需要的资源。所以路径对客户端来说真的无关紧要。我不喜欢它，因为它使用起来很混乱——不是因为违反了 REST 原则。

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

对于算法本身，通常实现一种最少或最多限制的类型算法，将允许的数据合并到响应中（非常类似于 java 领域或 Microsoft 的用户安全模型）。

如果受限/非受限情况下的数据结构不同，您可以创建两种不同的数据表示并返回用户有权查看的任何一种。无论如何，客户端都应该要求接受的 mime 响应类型，并且它只会根据请求标头中的会话安全性提供不同的答案。或者，您可以提供带有表示的可选元素，并根据授权填写适当的元素（尽管在我看来这有点骇人听闻）。

于 2012-06-20T04:59:44.963 回答