5

我想在超文本文档的文件夹中表示子文件夹和文档的链接（可能使用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 属性有一个明显的缺点，即使用这些文档的应用程序需要明确支持它们。因此，我宁愿使用应用程序可以通过遵循标准和最佳实践来理解的东西。

更新：AtomPub (RFC 5023) 似乎在指向集合成员的链接上使用 rel="edit"。我相信他们没有 sub.collection 的概念。来自 RFC-5988 的 rel="subsection" 可能是一个选项。

4

1 回答 1

3

表示层次结构 表示层次结构的
一种非常常见的方法是使用层次结构中各个级别之间的父子关系的概念。这允许您非常笼统地描述层次结构，而无需将自己束缚于仅表示文件夹和文档，因为父子/子可以表示任何层次结构。例如，DOM 解析器大量使用这个概念，因为 DOM 是一个层次结构。

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

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

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

标准不是万能
的 一般而言，对于您的应用程序来说，以您的应用程序需要的方式表示它自己的资源比您试图将您的表示形式硬塞进某个“标准”更为重要。如果您的应用程序使用、和最有意义，那么一定要使用这些链接关系。唯一的警告是，我要认真考虑一下您将来可能要如何改变事情。更改 API 并不是最简单的事情，但引入新的内容类型并弃用旧的内容类型并不太难。upfolderfile

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

于 2012-10-31T13:05:17.503 回答