Question

鉴于user和comment之间存在一对多的关系，并且所有ID都是唯一的;

将操作命名为：

之间的注意事项

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

或

DELETE /comments/{comment_uuid}？

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

Answer 1

两者都可以很好地用于结构良好的RESTful资源 - 只要comment_uuid确实是一个uuid。既没有暗示潜在的实现，也没有让我感到尖叫this is an RPC service：）

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

话虽如此，我更喜欢第一个，因为它强化了语义信息，这是user评论。我可以看到这一点，并且在不提出请求的情况下知道我正在回复的内容。

评论是一个很难显示反案例，因为大多数评论来自用户，但想想这个......可以想象，你可以有一些其他类型的实体留下评论，想象在你的系统中注册机器人{{ 1}}，

现在，如果您只使用/bot/{bot_uuid}，那么您刚刚删除了用户或机器人评论吗？

在您扫描代码与/comment时进行比较。 IMOP越清晰越清楚。

最后，如果有人提供特定评论的获取请求/bot/{bot_uuid}/comment/{comment_uuid}我知道该用户的URL，只需删除该部分即可。当然，大多数人可能会猜测，/users/{user_uuid}/comments/{comment_uuid}，但就像我说的那样，用户和评论都是不好的例子，因为你获得了更多的非典型资源名称，它变得不那么明显了。问题是，如果你总是明确的，你不必担心资源看起来像这样：

/user/{user_uuid}

现在你会做部分：

  /widget/{widget_uuid}/contrawidget/{co_uuid}/parts/{part_uuid}
  /spaceframe/{spaceframe_uuid}/parts/{part_uuid}

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

Answer 2

是否值得保持user_uuid只是为了让网址看起来像RESTful？

没有。通过使标识符看起来RESTful而获得的业务价值与零无法区分。

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

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

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

这些是不同的标识符;因此，就客户而言，它们是不同的资源。这意味着，就客户而言，它们是单独缓存的。 Invalidating one不会使另一方失效。

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

Answer 3

我认为你的问题是设计问题，而不是像@ray所说的那样的RESTful问题，并且对于所有设计问题，答案是......取决于。

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

但对于这类问题，我使用Entity-Control-Boundary Pattern (EBC)它基本上提出了一个表单，在某些实体的上下文中与您的应用程序进行交互，而不是使用系统的所有实体，只使用关键的实体，我通常使用它作为我的规则来识别更有意义的路径。

REST API命名约定：使用嵌套路径引用唯一资源

3 个答案: