Question

在阅读“ REST API最佳实践”时，通常建议按层次结构命名资源，如下所示：

https://api.example.com/projects/{projectid}/documents/{documentid}

现在，我想通过可以具有任何深度的路径来命名资源，以便可以像这样定位资源（例如项目）：

 https://api.example.com/projects/{group}/{projectname}

或

https://api.example.com/projects/{group}/{subgroup}/{projectname}

但是现在按层次命名资源是模棱两可的，因为：

https://api.exmaple.com/projects/mygroup/mysubgroup/projectname/documents/document1

可以在路径document1中引用项目/mygroup/mysubgroup/projectname/documents/，这是不正确的。

还对项目执行的操作，例如：

https://api.exmaple.com/projects/mygroup/mysubgroup/projectname/edit

有同样的问题。

使用REST方式处理具有分层结构的路径命名资源的方法是什么？

Answer 1

我认为这个问题不能回答，只是讨论。

对于 CRUD 应用程序，请考虑为每个资源使用具有唯一ID（ URI ）的平面路径。

/groups/:id
/documents/:id
/projects/:id

然后根据需要关联您的实体，并添加其他查询端点。

示例：

/search?group=id&subgroup=id&document=id&project=id

在更高级的 REST 方法中，HTTP-Path与资源本身更加独立。通过发送HTTP请求，您正在询问“某些”资源的某种表示形式。这不仅由路径表示，而且由媒体类型（在HTTP标头中发送）表示。您的客户可以致电...

GET -H"accept:application/vnd.myapi.subgroup" /documents/document1

...可能会导致与

不同的响应

GET -H"accept:application/vnd.myapi.document" /documents/document1

Answer 2

处理具有层次结构的路径命名资源的RESTful方法是什么？

REST是一种建筑风格，而不是^{（请参阅以下说明）}的URI设计指南。 REST不执行任何URI设计，完全由您来选择可以更好地标识资源的URI。

虽然长URI可以完成资源识别，但是发送多个 path参数可能对您的客户端来说很麻烦。因此，您可能需要考虑短URI：

/documents/{id}

/projects/{id}

/groups/{id}

短URI更容易记住，您始终可以使用查询参数来过滤资源。

^{注释1： URI语法在RFC 3986中定义。通常，该路径以 hierarchical 形式组织（各段之间用/分隔），并且可以在查询组件中（从?开始包含非分层数据）。}

^{注释2： REST体系结构样式在Roy T的chapter 5中进行了描述。Fielding的论文中定义了一组约束，应用程序必须遵循这些约束遵循这样的架构。但是，它并没有说明URI必须是什么样。}

^{注释3： Martin Fowler撰写的popular article的示例解释了伦纳德·理查森（Leonard Richardson）定义的模型<建议> >看起来友好且易于阅读的URI结构。}