假设我的模型由Parent实体组成，该实体通过Child属性引用一些children个实体。根据REST原则，特定Child的URI的路径段为/parent/{parentId}/children/{childId}。
在Child上执行更新操作时，通常childId是我唯一需要的，以便唯一地标识正确的Child，从而认为路径中的parentId段是多余的。随着层次结构变得复杂，这种冗余会加剧。
现在我想到了它，它也可能会导致意外行为：访问具有相同childId但具有不同 parentId的URI可能会导致相同的行为，如果程序员不知道。在不相关的Child下访问Parent时可能发生的情况是应返回客户端错误代码。
目前我认为可能不会在REST API中引入任何层次结构，除非它非常直观，因为它：
有没有办法逃避这种冗余并仍然符合REST原则？
答案 0 :(得分：4)
是的，只需像这样构建您的网址......
/children/{childId}
由于您可以从服务器端的子项推断父项，因此没有理由在URL中声明它。在绝对需要时，您应该只在URL中放置多个资源。例如，用户对评论进行投票。由于在数据库方面没有正式的方法来确定，你可以创建一个像..
这样的URL /voter/{userId}/comment/{commentId}/upvote
答案 1 :(得分：1)
由于REST指的是资源，因此它们不一定必须是分层的。
在类似的API中，我有章节，类别和文章。当然，其中每个都在另一个之下，但在REST中我将它们指定为section / {id}＆amp;文/（编号）。它们仍然是单个资源的链接 - 但由于它们可以独立于父级，因此在URI中指定层次结构并不重要。
如果您肯定要在URI中指定层次结构，则应检查以确保父项是父项的父项，并在其他方面抛出错误 - 以保持层次结构的完整性。
TL; DR
答案 2 :(得分：1)
对我来说，这个问题的答案将由数据建模驱动，对于数据建模，如果他使用复合键，那么问题是“是否使用子模型的复合键”，因此您必须将父ID放在URI中如果没有，并且子拥有自己的不是复合的id，那么你只能使用带有子id的URL。
所以这是数据建模问题!!!