鉴于users 和comments 之间存在一对多关系，并且所有id 都提供为唯一的；
将操作命名为：
DELETE /users/{user_uuid}/comments/{comment_uuid}
或
DELETE /comments/{comment_uuid}?
在以前的user_uuid 中是多余的，因为不需要删除评论。是否值得保留 user_uuid 只是为了让 url 看起来像 RESTful？
【问题讨论】：
uri-design而不是rest来标记，因为这与REST本身几乎没有任何关系。此外，这是相当自以为是的。关于 URI 设计：问问你自己，如果你删除了一个用户，他的所有帖子都应该被删除吗？如果是，则将帖子设为用户的子资源，如果不是，则将其保留为顶级资源。
标签： rest url uri url-design
两者都适用于结构良好的 RESTful 资源——只要 comment_uuid 确实是一个 uuid。既没有暗示底层实现，也没有让我感到尖叫this is an RPC service :)
无论您选择什么，第 1 条规则... 保持一致。
话虽如此，我更喜欢第一个，因为它强化了语义信息，即这是 user 评论。我可以看到并且几乎知道我会得到什么，而无需提出请求。
评论是一个不好的反例，因为大多数 cmets 来自用户，但考虑一下...可以想象，您可能有一些其他类型的实体离开 cmets，想象在您的系统中注册机器人 @987654325 @,
现在，如果您只使用 /comment，您是否只是删除了用户或机器人评论？
在您扫描代码时将其与/bot/{bot_uuid}/comment/{comment_uuid} 进行比较。 IMOP 越详细越清晰。
最后，如果有人提供特定评论的获取请求/users/{user_uuid}/comments/{comment_uuid} 我知道用户的 URL，只需删除 omment 部分。当然，大多数人可能会猜到，/user/{user_uuid}，但就像我说的，用户和评论是不好的例子，当你获得更多非典型资源名称时，它变得不那么明显。问题是，如果你总是很明确，当资源看起来像这样时，你不必担心：
/widget/{widget_uuid}/contrawidget/{co_uuid}/parts/{part_uuid}
/spaceframe/{spaceframe_uuid}/parts/{part_uuid}
现在你会做部分吗：
/parts/{part_uuid}
可能不会，因为它可能会让消费者感到困惑
【讨论】：
REST valid?
/user/{user_id}/change_password
self-interested 等同于 selfish 的定义——当然，但从实际/口语意义上来说，它们不能互换使用。
是否值得保留 user_uuid 只是为了让 url 看起来是 RESTful 的？
没有。使标识符看起来像 RESTful 所获得的商业价值与零无异。
您可能出于其他原因这样做：URI 设计主要是为了让人们更轻松地做事。就机器而言，所有的 URI 都可能只是 UUID，没有其他提示。
也就是说，有一些重要的事情需要考虑......
/users/{user_uuid}/comments/{comment_uuid}
/comments/{comment_uuid}
这些是不同的标识符；因此，就客户端而言，它们是不同的资源。这意味着，就客户端而言，它们是单独缓存的。 Invalidating one 不会使对方无效。
（当然，其他客户端不知道 DELETE 发生了，将继续使用 both 资源的缓存副本。缓存失效是两个难题之一。
【讨论】：
我认为您的问题是设计问题，而不是 @ray 所说的 RESTful 问题，就像所有设计问题一样，答案是......取决于。
我也更喜欢第一个，因为没有用户，评论（据我所知是评论）不可能存在。
但是对于这类问题，我使用Entity-Control-Boundary Pattern (EBC)，它基本上提出了一种在某些实体的上下文中与您的应用程序交互的表单，而不是使用系统的所有实体，只是关键的，我一般使用这个作为我的规则来确定更有意义的路径。
【讨论】：