2

user假设s 和s之间存在一对多的关系comment，并且所有 id 都被提供为唯一的；

将操作命名为：

DELETE /users/{user_uuid}/comments/{comment_uuid}

或者

DELETE /comments/{comment_uuid}?

前者user_uuid是多余的，因为不需要删除评论。user_uuid只是为了让 url 看起来是 RESTful值得保留吗？

4

3 回答 3

3

两者都适用于结构良好的 RESTful 资源——只要comment_uuid它确实是一个 uuid。既没有暗示底层的实现，也没有让我尖叫this is an RPC service:)

无论您选择什么，规则 #1...保持一致。

话虽如此，我更喜欢第一个，因为它强化了这是user评论的语义信息。我可以看到并且几乎知道我会得到什么，而无需提出请求。

评论是一个不好的反例，因为大多数评论来自用户，但考虑一下……可以想象，你可以有一些其他类型的实体留下评论，想象在你的系统中注册机器人/bot/{bot_uuid}，

现在，如果您/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}

可能不是，因为它可能会让消费者感到困惑

于 2017-04-10T17:55:01.243 回答
1

是否值得保留 user_uuid 只是为了让 url 看起来像 RESTful？

不会。使标识符看起来像 RESTful 所获得的业务价值与零没有区别。

您可能出于其他原因这样做：URI 设计主要是为了让人类更轻松。就机器而言，所有 URI 都可能只是 UUIDS，没有其他提示。

也就是说，有一些重要的事情需要考虑......

/users/{user_uuid}/comments/{comment_uuid}
/comments/{comment_uuid}

这些是不同的标识符；因此，就客户而言，它们是不同的资源。这意味着，就客户端而言，它们是单独缓存的。 使一个无效并不会使另一个无效。

（当然，其他客户端不知道 DELETE 发生了，将继续使用这两种资源的缓存副本。缓存失效是两个难题之一）。

于 2017-04-10T18:50:41.843 回答
0

我认为您的问题是设计问题，而不是@ray 所说的 RESTful 问题，就像所有设计问题一样，答案是......取决于。

我也更喜欢第一个，因为没有用户，评论（据我所知是评论）不可能存在。

但是对于这类问题，我使用实体控制边界模式（EBC），它基本上提出了一种在某些实体的上下文中与您的应用程序交互的表单，而不是使用系统的所有实体，只使用关键实体，我通常将此作为我的规则来识别更有意义的路径。

于 2017-04-10T18:03:32.650 回答