请考虑具有3个资源：reports，comments和attachments。 report可以有很多comments，而comment可以有很多attachments。
此外，只有特定attachments拥有权限的用户才能访问附加到特定report（在报告->注释->附件树中）的report
现在，在设计REST API时，我喜欢平面URL结构，但是在上述情况下，我不知道如何在不创建如下很长的资源的情况下做到这一点：
/reports/:id/comments/:id/attachments/:id
是否有任何方法可以满足这些要求（权限），并能够通过像attachment这样的固定URL到达/attachments/:id？
还是我有点夸张，拥有这些长资源URL完全可以吗？
免责声明：我创建了一个attachments资源（而不是report-attachments），因为还有其他资源也需要拥有attachments-我不想复制结构。
答案 0 :(得分：1)
拥有这类长资源网址完全可以吗？
拥有任何类型的资源URL都是可以的。 REST不在乎您如何拼写资源标识符-这就是重点。因此，如果您由于服务器需要在其中编码大量信息而需要一个日志URL，就可以了。
如果您担心长度，可以删除语义提示
/reports/:id/comments/:id/attachments/:id
/reports/:id/c/:id/a/:id
/reports/:id/:id/:id
/:id/:id/:id
对于您在服务器上使用的 routing 框架，其中一些拼写会更容易，但这是您控制的实现细节。
没有规则说您必须将信息直接编码到标识符中； URL缩短器工作。
在HTML中，我们还具有通过表单从客户端提供的信息中构造（某些）标识符的能力。这是因为HTML媒体类型的定义包括处理规则，这些处理规则描述了如何将表单数据组合为查询部分中包含的application/x-www-form-urlencoded表示形式。
因此，您可以在自己的媒体类型中引入类似的机制。
还有RFC 6570，它描述URI模板。这为您提供了与客户端进行通信的另一种方式，如何将信息编码为URL。
有什么办法可以满足这些要求（权限），并能够通过像/ attachments /：id这样的纯URL来访问附件？
好的。您只需要能够使用:id来查找/计算正确的权限集，然后检查请求以查看权限是否得到满足。