REST：处理部分受限资源的正确方法答案

【问题标题】：REST: Proper way to handle partially-restricted resourcesREST：处理部分受限资源的正确方法
【发布时间】：2021-12-10 17:28:27
【问题描述】：

我正在为我构建的一个小型 SaaS 重新设计 REST API。目前有一个路由/entries 不需要任何身份验证。但是，如果客户端以足够的权限进行身份验证，服务器将发送附加信息（例如：与每个条目关联的帐户）。

我看到的主要问题是，尝试请求权限不足的受保护数据的客户端仍会收到 200 响应，但没有预期的数据，而不是 401 Unauthorized。

我想出的替代方案是：

将端点分成两个端点，例如/entries 和/admin/entries。这种方法的问题在于，现在对于本质上相同的资源有两个不同的端点。但是，它具有易于使用 OpenAPI 记录的优点。（此外，它允许添加 /entries/:id/account 端点。）
接受查询参数?admin=true。这个选项更难记录。另一方面，它避免了单个条目有多个 URI。

有没有标准的方式来构建这样的东西？

【问题讨论】：

我认为这个问题对于这个网站来说太基于意见了。底线是 REST 并不是为了惯用地处理这样的复杂逻辑而构建的。这也是构建 GraphQL 的原因之一。您描述的两种方法都在大型科技公司中广泛部署。选择一个而不是另一个的决定通常是由确切的用例驱动的。例如，如果客户是外部客户并且拥有自己的复杂分租系统与只是内部管理员相比，“易于记录”就完全不同了。无论哪种方式，您都必须根据自己的用例进行选择

【解决方案1】：

我想出的替代方案是

请注意，就 HTTP/REST 而言，您的两种选择相同：在这两种情况下，您都在引入新资源。

在一种情况下您使用路径段来区分两个标识符，而在另一种情况下您使用查询部分这一事实并没有改变您拥有两个资源的事实。

拥有两个具有相同信息的资源很好 - 想象一下使用相同信息构建的两个网页。

这是一种权衡 - HTTP 应用程序不会知道这些资源具有公共信息，因此不会知道使一个缓存资源无效也会使另一个无效。因此，就像网页一样，您可能会遇到缓存中的表示相互不一致的情况。

有时，正确的答案是使用不同资源之间的链接 - 将“该”信息放在一个地方，而其他任何地方都有可以让您找到那个地方的链接。再次，权衡。

HTTP 不是一个无限灵活的应用程序协议。在transferring documents over a network 上真的很棒，尤其是在“网络规模”上。

已经尝试使用Link headers to trigger invalidation 的其他缓存资源，但据我所知，它们都没有通过提案阶段。

【讨论】：