我正在尝试为类似文件系统的Web服务设计RESTful接口。为了在各种资源（文件，目录等）之间提供超链接性，我想我会使用XLink。但是，似乎XLink有一个奇怪的遗漏：内容类型。
Atom提供了一个属性来指定链接的内容类型以及链接资源与当前的关系，如：
<link rel="alternate" type="text/html" href="http://example.org"/>
因为我正在为每个资源的表示创建自定义内容类型，所以这似乎是我的超链接中包含的重要信息。
我可以在XLink规范（＆strong>标签，从和到中模拟 rel >，我猜？），但为什么XLink缺少内容类型？他们是否打算角色以某种方式表达客户在链接末尾发现的内容？也许我错过了XLink的目的？
答案 0 :(得分：2)
看来xlink故意忽略了这一点;媒体类型或表示的唯一提及与片段标识符的解释方式有关。 XLink实际上只定义了资源之间的链接，而不是它们的表示。
这意味着如果您使用XLink，则必须定义自己的方式来指定链接目标的预期媒体类型，而如果使用Atom的链接，则会获得目标媒体类型，但不会获得XLink的多功能性。
由于您可能正在定义自己的媒体类型，因此除非您希望不知道您的媒体类型的通用客户端能够解析嵌入的链接，否则它并不是非常重要。 任何了解您的媒体类型的客户都可以阅读您的文档，并且知道使用XLink，Atom，HTML（link元素）或您自己的专有链接语义。
仅作为后者的示例：Sun Cloud API使用具有rel的对象的JSON列表，以及用于传出链接的href属性。