基于用户查看权限的不同REST资源内容 [英] Different REST resource content based on user viewing privileges

查看:128
本文介绍了基于用户查看权限的不同REST资源内容的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I want to provide different answers to the same question for different users, based on the access rights. I read this question:

在RESTful响应中排除私有数据

但是我不同意接受的答案,该答案指出您应同时提供 / people.xml /unauthenticated/people.xml ,因为我对REST的理解是,特定资源应位于特定位置,而不是多个

But I don't agree with the accepted answer, which states that you should provide both /people.xml and /unauthenticated/people.xml, since my understanding of REST is that a particular resource should live in a particular location, not several depending on how much of its information you're interested in.

我正在设计的系统比该系统还要复杂。假设用户创建了多个朋友圈,并为其分配了不同的访问权限。例如,我的熟人圈子可以访问我的生日,而我的专业圈子可以访问我的工作经历,但反之则不行。为了应用我提到的问题的答案,我需要一种获取所有用户圈子的方法(出于安全原因,我可能希望对其保密),然后通过 / circles / a / users / 42 / circles / b / users / 42 / circles / c / users / 42 等,然后合并结果以显示最大可用信息量。 很显然,不一定有一个圈子可以获取其他圈子获得的所有信息。我相信这很棘手(请注意,我可能需要对几种对象以及未来的事物进行处理)版本可能需要一个不同的过程),但是如果我想对特定用户强加安全限制,尽管该用户也确实在我的某些圈子中,这会怎么办?这个问题可以解决吗?即使我拒绝回答上述任何一个查询并提出一个可以给我答案的新查询,它仍然表明,由于个人访问限制,该特定用户的待遇有所不同。

The system I'm designing is even more complicated than that one. Let's say that a user has created a number of circles of friends, and assigned different access rights to them. For example, my "acquaintances" circle might have access to my birthday, and my "professional" circle might have access to my employment history, but not the other way around. In order to apply the answer from the question I mentioned, I need to have a way of getting all of the user's circles (which I might want to keep secret for security reasons), and then go through /circles/a/users/42, /circles/b/users/42, /circles/c/users/42 and so on, and then merge the results to display the maximum amount of information available. Obviously there's not necessarily a single circle that gets all the information that any of the other circles get. I believe this is tricky enough (note that I probably need to do this with several kinds of objects and that future versions might require a different procedure), but what if I want to impose security restrictions on a particular user despite the fact that he's also in some of my circles? Can that problem even be solved? Even if I refuse to respond to any of the above-mentioned queries and come up with a new one that could give me an answer, it'd still reveal the fact that this specific user is treated differently due to individual access restrictions.

我在这里想念什么?

如果我得出的结论是该行为不是RESTful,那么这仍然构成一种情况吗?在道德上可以打破REST合同吗?如果是这样,负面影响是什么?例如,是否冒着代理缓存问题的风险?

If the conclusion is that the behavior is not RESTful, would this still constitute as a situation where it'd be morally okay to break the REST contract? If so, what are the negative implications? Do I risk proxy caching issues for example?

推荐答案

根据菲尔丁的论文(这确实是很棒的著作):

According to Fielding's dissertation (it really is a great writing):


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

A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

换句话说,如果您有一个定义为请求用户的已分配项目的资源,并且其表示可通过<$ c的URI访问$ c> / projects ,您不会违反REST的任何限制,因为当用户A获得相同的URI时,将为其返回一个项目列表(即表示形式),为用户B返回另一个项目(表示形式)。

In other words, if you have a resource that is defined as "the requesting user's assigned projects" and representations thereof accessible by a URI of /projects, you do not violate any constraints of REST by returning one list of projects (i.e., representation) for user A and another (representation) for user B when they GET that same URI. In this way, the interface is uniform/consistent.

除此之外,REST仅规定响应中包含显式缓存指令,无论该指令是否为 cache长时间或根本不缓存:

In addition to this, REST only prescribes that an explicit caching instruction be included with the response, whether that is 'cache for this long' or 'do not cache at all':


缓存约束要求对请求的响应中的数据是隐式的,或者明确标记为可缓存或不可缓存。

Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.

如何选择取决于您自己的管理方式。

How you choose to manage that is up to you.

记住这一点

返回资源的表示应该感到很舒服

You should feel comfortable returning a representation of a resource that varies depending on the user requesting a representation of a particular resource, as long as you are not violating the constraints of a uniform interface -- don't use a single resource identifier to return representations of different resources.

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

If it helps, consider that the server responds with varying representations of a resource as well -- XML or JSON, French or English, etc. The credentials sent with the request are just another factor the server is able to use in determining which representation to to send in response. That's what the header section is there for.

这篇关于基于用户查看权限的不同REST资源内容的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆