自定义内容类型：XLink 与 Atom
我正在尝试为类似文件系统的 Web 服务设计一个 RESTful 接口。为了提供各种资源（文件、目录等）之间的超链接性，我想我会使用 XLink< /a>.然而，XLink 似乎有一个奇怪的遗漏：内容类型。
Atom 提供了一个属性来指定链接的内容类型以及链接资源与当前资源的关系，如下所示in：
<link rel="alternate" type="text/html" href="http://example.org"/>
因为我正在为每个资源的表示创建自定义内容类型，所以这似乎是要包含在我的超链接中的重要信息。
我可以在 XLink 规范中找到一个与 rel 类似的东西（label、from 和 to，我猜猜？），但为什么 XLink 中缺少内容类型？他们是否打算让角色以某种方式传达客户在链接末尾发现的内容？也许我错过了 XLink 的目的？
I'm trying to design a RESTful interface for a filesystem-like web service. To provide hyperlinkability among the various resources (files, directories, etc.), I thought I would use XLink. However, it seems there is a strange omission from XLink: content types.
Atom provides an attribute to specify the content type of links as well as the linked resource's relationship to the current, as in:
<link rel="alternate" type="text/html" href="http://example.org"/>
Because I am creating a custom content type for each of my resources' representations, this seems like an important bit of information to include in my hyperlinks.
I can kind of make out an analog to rel in the XLink spec (label, from and to, I guess?), but why is content type missing from XLink? Do they intend that the role is somehow meant to convey what a client finds at the end of a link? Perhaps I missed the purpose of XLink?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来 xlink 故意忽略了这一点；唯一提及的媒体类型或表示与如何解释片段标识符有关。 XLink 实际上只定义资源之间的链接，而不是它们的表示。
这意味着，如果您使用 XLink，您必须定义自己的方式来指定链接目标的预期媒体类型，而如果您使用 Atom 的链接，您将获得目标媒体类型，但无法获得 XLink 的多功能性。
由于您可能正在定义自己的媒体类型，因此它并不是非常重要，除非您希望不知道您的媒体类型的通用客户端能够解析嵌入的链接。 任何了解您的媒体类型的客户端都可以阅读您的文档，并且知道如何使用 XLink、Atom、HTML（
link元素）或您自己的专有链接语义。作为后者的一个示例：Sun Cloud API 使用带有 rel 和 href 属性的对象的 JSON 列表作为传出链接。
It appears xlink has purposely ignored this; the only mention of media types or representations has to do with how fragment identifiers are to be interpreted. XLink actually only defines links to be between resources, and not their representations.
This means that if you used XLink you have to define your own way of specifying the expected media type of the target of the link, whereas if you use Atom's link you get the target media type, but not the versatility of XLink.
Since you're probably defining your own media type, it's not extremely important unless you want generic clients that don't know of your media type to be able to parse the embeded links. Any client that knows about your media type can read your documentation, and will know to use XLink, Atom, HTML (the
linkelement) or your own proprietary link semantics.Just as an example of the latter: The Sun Cloud API uses a JSON list of objects with rel, and href attributes for outgoing links.