我想在超文本文档中表示指向文件夹中的子文件夹和文档的链接(可能使用 HAL )。因此，表示文件夹的文档应具有指向父文件夹、子文件夹和文件夹中包含的文件的链接。 对于父文件夹， 似乎是最直接的选择。但是，我不确定什么最适合链接到文件夹中包含的子文件夹和文档。 RFC-5988 中定义了几个选项.但是，我不能说哪个最适合表示文件夹和文件树。
我可以提出自己的值(value)观并制作文件。例如(为了熟悉而使用 HTML 语法而不是 HAL):
...
<link rel="self" href="http://example.com/some/folder/">
<link rel="up" href="http://example.com/some/">
<link rel="file" href="image1.jpg">
<link rel="file" href="image2.png">
<link rel="folder" href="subfolder/">
...
使用自定义 rel-attributes 有一个明显的缺点，即使用这些文档的应用程序需要明确支持它们。因此，我宁愿使用应用程序只需遵循标准和最佳实践即可理解的内容。
更新: AtomPub (RFC 5023) )似乎在指向集合成员的链接上使用 rel="edit"。我相信他们没有 sub.collection 的概念。 RFC-5988 中的 rel="subsection"可能是一个选项。
最佳答案
表示层次结构
表示层次结构的一种非常常见的方法是使用层次结构中级别之间的父子关系概念。这使您可以非常笼统地描述层次结构，而不必将自己束缚于仅表示文件夹和文档，因为父子/子代可以表示任何层次结构。例如，DOM 解析器大量使用这个概念，因为 DOM 是一个层次结构。
假设您的层次结构不是完全平衡的(即，您可以有 3 层深度的文档，也可以有 20 层深度的文档)，您需要知道您所在的“节点”类型，无论是集合(文件夹)或一片叶子(文件)。有了集合与叶、父与子/子的概念，您将能够轻松地标记出您应该需要的所有链接的关系。
内容类型
任何 REST 交互中最重要的部分是在客户端和服务器上明确定义内容类型。内容类型就它们实际需要的内容而言相当模糊，但出于您的目的，它可能只是表明一般资源“格式”是 HAL，并且还会定义 parent 的含义。和 child相对值。
大多数人忘记了内容类型是为人类准备的。只有内容类型的名称对用户代理很重要，而不是内容类型定义的内容。开发人员(或非常 聪明的用户代理)使用内容类型定义来决定如何解释事物。用户代理只是使用名称来切换解释模式。
标准不是一切
一般来说，对于您的应用程序来说，以您的应用程序需要的方式来表示它自己的资源比您尝试将您的表示硬塞进一些“标准”更为重要”。如果您的应用程序使用 up 最有意义, folder , 和 file ，一定要使用那些链接关系。唯一的警告是我要认真考虑你可能想要如何改变 future 的事情。更改 API 并非易事，但引入新的内容类型并弃用旧内容类型并不太难。
不要误会我的意思，我完全支持标准，但就其本质而言，它们几乎总是落后于现实世界。例如，RCF 似乎不能很好地处理事物的通用层次集合。
关于html - 链接标签的 rel-attribute 的哪些值应该用于表示集合和文档的层次结构？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12854930/