REST的URI来反映资源的关系？

Posted 2023-03-31

【中文标题】REST的URI来反映资源的关系？

【英文标题】：URI of REST to reflect relationship of resources?

【发布时间】：2016-05-17 14:01:16

【问题描述】：

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

但由于 URI 应该反映资源的关系，我有点困惑。以 SO 为例，当更新一个已存在的答案评论时，URI 应该是这样的：

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

但是我在使用这个so-called standard URI 时感觉很尴尬，因为：

有点啰嗦，尤其是层次分明的时候 深的。 questionId 和 answerId 在这里完全没有必要，因为 commentId 足以让服务器识别评论记录。

那么处理这个问题的适当方法是什么？我应该始终遵循名称转换，还是在资源的关系层次非常深时进行一些更改？

【参考方案1】：

我强烈反对“URI 应该反映资源的关系”。

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

【参考方案2】：

它为您提供更多选择，而无需提出额外的要求。

因此允许您调用可能需要说 questionId 的函数。 当您只有 commentId 时，您必须先查询您的 questionId。

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

这就是我对您应该如何看待标准添加选项的看法

【参考方案3】：

我会将路由/URI 简化为：

 PUT /comments/commentId

连同相应的RequestBody，可能是某种DTO。 URI 不必从上下文路径一直显示层次结构。可以是能够唯一标识资源的最短URI