REST API中嵌套资源的权限 背景

考虑使用3种资源：

报告

、

评论

和

附件

。

报告

可以有许多

注释

，而

注释

可以有许多

附件

此外，只有对特定

报告

具有权限的用户才能访问附加到特定

报告

（在报告->注释->附件树中）的

附件

问题:
现在，我在设计REST API时非常喜欢平面URL结构，但是在上面的例子中，我不知道如果不创建一个非常长的资源，我怎么能做到这一点，比如：

/reports/:id/comments/:id/attachments/:id

有没有办法满足这些要求（权限）并能够从像
/attachments/：id
这样的平面URL访问
附件
？

或者我有点夸张了，有这样的长资源URL完全可以吗？

免责声明：我创建了一个
附件
资源（而不是
报告附件
），因为还有其他资源也需要有
附件
——我不想复制该结构

有这样的长资源URL完全可以吗

它完全可以有任何类型的资源URL。REST不关心如何拼写资源标识符——这就是重点。因此，如果您需要一个日志URL，因为服务器需要将大量信息编码到该URL中，这很好

如果您担心长度，可以去掉语义提示

/reports/:id/comments/:id/attachments/:id
/reports/:id/c/:id/a/:id
/reports/:id/:id/:id
/:id/:id/:id

其中一些拼写对于您在服务器上使用的路由框架来说会更容易，但这是一个由您控制的实现细节

没有规则规定必须将信息直接编码到标识符中；URL缩短器可以工作

在HTML中，我们还能够通过表单从客户机提供的信息构造（一些）标识符。这是因为HTML媒体类型的定义包括处理规则，这些规则描述了如何将表单数据组装成查询部分中包含的
应用程序/x-www-form-urlencoded
表示

因此，您可以在自己的媒体类型中引入类似的机制

还有，它描述了URI模板。这为您提供了与客户机通信的另一种方式，即如何将信息编码到URL中

是否有任何方法可以满足这些要求（权限），并能够从/attachments/：id这样的平面URL访问附件

当然。您只需要能够使用
：id
来查找/计算正确的权限集，然后检查请求以查看权限是否得到满足。
谢谢您详细的回答！：）与此同时，我意识到我可以计算
/attachments/：id
端点上的权限，但这需要查找父节点。漫长的道路将更容易实现。不管怎样，你给了我足够的选择让我思考，所以我觉得我的问题已经得到了回答！