3

我有一个类似这样的简单资源：

/api/{configuration}/exhibitors/{id}

这通常是一个公共 API，具体取决于 URL 的配置部分的设置。

它可能会将其返回给未经身份验证的用户：

{ "a" : "some value", "b" : "other value" }

但是，如果管理员登录并想要获取此资源，他们会期望在同一资源上出现一些稍微不同的数据：

{ "a" : "some value", "C" : "admin only value" }

我是否应该检测此管理员权限并仅从同一 URL 返回不同的内容？

或者我应该有一个新的 URL 来标识它是为谁服务的并且内容可能不同？

/api/admin/{configuration}/exhibitors/{id}

我的想法是我不喜欢额外的 URL，但如果我不会根据用户更改内容，我将更容易缓存公共内容。

管理员调用没有理由无法获取资源的完整公共版本以及额外的仅限管理员字段，但在我的示例中它们可能实际上不需要字段“b”，所以我宁愿管理员表示有点轻。

4

2 回答 2

2

根据情况，这两种选择都是可行的。正如您所提到的，允许表示形式的变化将使缓存变得困难。但是，支持不同的资源会产生额外的开销。理想情况下，您的服务器端框架可以轻松创建额外资源，因此开销应该是最小的。

另一种选择是返回公共版本，并提供一个嵌入的超链接到仅包含附加“仅限管理员”属性的资源。如果您的客户可以轻松处理超媒体，那将成为一个相当灵活的选择。

于 2013-07-08T13:21:04.210 回答
1

我想经过身份验证的用户将是提供用户 ID 和密码的人，即登录。用户登录后，大多数 REST 应用程序倾向于依赖 cookie 来确定请求是否来自经过身份验证的用户。

理想情况下，每个用户都应该有自己的上下文。一个用户的 /tmp/foo 与另一个用户的 /tmp/foo 不同。您仍然可以拥有由以 /public 或类似名称开头的 URL 标识的公共内容。

出于安全原因，您确实不想将用户的 id 作为 URL 的一部分泄露。此外，用户 id 往往是用户的电子邮件或帐号。

管理员是一个特例，根据后端架构，可以实现一个解决方案，允许管理员访问其他用户的管理信息。

于 2013-07-08T15:32:48.773 回答