应使用link-tag的rel-attribute的哪些值来表示集合和文档的层次结构？

Question

我想代表超文本文档(可能使用HAL)文件夹中的子文件夹和文档的链接.因此,表示文件夹的文档应具有指向该文件夹中包含的父文件夹,子文件夹和文件的链接.对于父文件夹,<link rel ="up"href ="..">似乎是一个简单的选择.但是,我不确定什么是最适合链接到文件夹中包含的子文件夹和文档.RFC-5988中定义了几个选项.但是,我不能说哪一个最适合代表文件夹和文件树.

我可以拿出自己的价值观并制作文件.例如(使用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"可能是一个选项.

Answer 1

表示层次结构 表示
层次结构的一种非常常见的方法是使用层次结构中各级别之间的父子关系概念。这使您可以非常笼统地描述层次结构，而不必只代表文件夹和文档，因为父子/子对象可以代表任何层次结构。例如，DOM 解析器大量使用这个概念，因为 DOM 是一个层次结构。

假设您的层次结构不完全平衡（即您可以拥有 3 层深度的文档，也可以拥有 20 层深度的文档），您需要知道您所在的“节点”类型，是集合（文件夹）还是叶子（文档）。通过集合与叶子、父项与子项的概念，您将能够轻松地标记您需要的所有链接的关系。

内容类型
任何 REST 交互中最重要的部分是客户端和服务器端内容类型的明确定义。就其实际需要而言，内容类型相当模糊，但出于您的目的，它可能只是表明通用资源“格式”是 HAL，并且还定义了 和parentrelchild值的含义。

大多数人忘记了内容类型是针对人类的。对于用户代理而言，只有内容类型的名称才重要，而内容类型定义的内容则无关紧要。开发人员（或非常聪明的用户代理）使用内容类型定义来决定如何解释事物。用户代理仅使用名称来切换解释模式。

标准并不是一切
一般来说，对于您的应用程序来说，以应用程序需要的方式表示它自己的资源比尝试将您的表示硬塞到某些“标准”中更重要。如果您的应用程序使用、和最有意义，则务必使用这些链接关系。我唯一需要注意的是，认真思考你将来可能想如何改变事情。更改 API 并不是最容易的事情，但引入新的内容类型并弃用旧的内容类型也不是太难。upfolderfile

不要误会我的意思，我完全支持标准，但就其本质而言，它们几乎总是落后于现实世界。举个例子，RCF 似乎不能很好地处理通用的层次结构集合。