反映资源关系的REST URI？

Question

我知道一些name conversions of REST API，例如资源的名称应该是多元的，使用不同的HTTP方法具有相同的URI来对资源进行不同的操作，等

但作为URI应该反映资源的关系，我是一个有点困惑。因此，需要作为一个例子，当更新一个答案的存在评论，URI应该是这样的：

PUT /{contextPath}/questions/{questionId}/answers/{answerId}/comments/{commentId} 

但我觉得别扭使用这个so-called standard URI时，因为：

1. 这是一个有点冗长，特别是当分层很深时，就是 。
2. questionId和answerId在这里完全没有必要，因为 commentId足以让服务器识别评论记录。

那么处理这个问题有什么合适的方法呢？我应该始终关注名称转换，或者在资源关系等级为很深的情况下进行一些更改？

Answer 1

我断然不同意“URI应该反映资源的关系” addoption意见。

URIs是指向资源的指针。而已。有一些习惯使它们易于阅读，因此更容易处理。当然没有硬性规定，关系应该在URI路径上建模。随意以平面而不是分层的方式对资源进行建模。使用link来建模资源之间的关系，并使用查询参数来缩小集合的范围。

Answer 2

它给你更多的选项，而不必提出额外的请求。

因此，您可以调用可能需要说出问题ID的函数。 当你只有commentId你必须先查询你的questionId。

取决于你的功能需求。如果您在上一页有特定信息，并且必须在下一次再次使用它，为什么要查询两次？除非是敏感的问题显然不是。

这就是我对你应该如何看待你的标准

Answer 3

我将简化路由/ URI：以相应的RequestBody

PUT /comments/{commentId} 

沿，也许是某种DTO的。 URI不应该从上下文路径中一直显示层次结构。它可以是可以唯一标识资源的最短的URI