4

我正在设计一个超媒体 API，是的，一个带有超文本约束的 RESTful API。

系统的每个用户都将使用他们自己的凭据访问系统，因此我们处理的每个请求都经过身份验证和授权。每个用户通常都有特定的凭证，因此他们可能对每个集合具有不同的权限（例如，无、读、读/写）。

我们希望客户端使用它开始的一个 URI 进行初始化，它可能是一个 atom 服务文档，或者是 atom 集合的层次结构（草案 atom 层次结构扩展）。

我的问题基本上是用户应该看到同一个 URI 的不同表示，还是应该根据他们的权限将用户定向到不同的 URI？

例如：用户 A 和用户 B 在系统中具有不同的权限。他们使用不同的凭据登录到相同的起始 URI。成功的响应可能是以下两种之一：

  1. 200 OK，并且用户 A 在同一个 URI 上看到与用户 B 不同的东西
  2. 302（或其他重定向）每个用户到例如 /endpoint/userA （他们拥有）

可缓存性之间的权衡当然是最小的，因为资源仅由客户端缓存而不是由中介缓存，但也存在可见性的权衡（URI 包含（经过验证的）用户 ID）。最后，未来有可能允许用户 A（或超级用户）看到用户 B 看到的内容。

我不是在问 Twitter 或 Facebook 做什么，我更感兴趣的是 REST 实践者对此有什么看法。

4

3 回答 3

2

我的问题基本上是用户应该看到同一个 URI 的不同表示，还是应该根据他们的权限将用户定向到不同的 URI？

例如：用户 A 和用户 B 在系统中具有不同的权限。他们使用不同的凭据登录到相同的起始 URI。成功的响应可能是以下两种之一：

  1. 200 OK，并且用户 A 在同一个 URI 上看到与用户 B 不同的东西
  2. 302（或其他重定向）每个用户到例如 /endpoint/userA （他们拥有）

两种方式都是 RESTful 的。资源的表示可以取决于权限。通信是无状态的，因为您通过每个请求发送带有 http auth 的凭据（用户名、密码）。在权限检查后重定向到另一个表示变体是一个好主意。这样，您可以将授权逻辑与资源表示逻辑完全分离，因此您甚至可以将其移动到另一台服务器，并且您可以创建非常好的可缓存资源表示。例如，GET /endpoint/userA您可以重定向userA到/endpoint/userA?owner=true，因为她是个人资料的所有者，或者您可以创建特征组合：/endpoint/userA?feature1=true&feature2=false等等...为此设置细粒度的访问控制非常容易。如果您将用户 ID 附加到每个请求的 queryString 中，则另一种保持可缓存的方法，但这种重定向解决方案更简洁。谢谢你！

于 2013-12-02T15:25:37.007 回答
1

就我个人而言，我觉得这是一个非常艰难的决定，我认为这在很大程度上取决于内容会发生多少变化。如果不同之处在于遗漏了一些额外的细节，那么我可能会将其视为根据用户而异的单一资源。

但是，一旦差异开始变得更加显着，我就会考虑创建不同的资源。我仍然会尝试避免创建特定于特定用户的资源。也许对于特定资源，您可以创建一组具有不同内容级别的子资源。例如

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

在某些情况下，这种方法与 302 结合使用可能就足够了。对于更复杂的情况，您可以使用多个查询字符串参数。

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

我不相信这个问题有一个简单的答案。我认为答案类似于最棘手的 REST 场景：只要您不违反约束，您的解决方案就可以随心所欲地发挥创意 :-)

于 2010-07-12T01:45:07.447 回答
0

选项 1，回复 200 是可接受的 REST 响应，并且比选项 2 更加用户友好。

Google 数据 API 在其用户服务之上提供了一个不错的 REST 实现，并且它们实现了选项 1。例如，Google 日历数据 API允许用户通过在http://www上执行 HTTP GET 请求来查询该人自己的提要.google.com/calendar/feeds/default/private/full。

于 2010-07-11T22:53:58.817 回答