我目前正在设计纯粹面向资源的企业服务。在阅读了几篇博客，书籍等之后，我相信REST与超媒体链接是可行的方法。
然而，所有这些博客和书籍都说的一件事是在响应中使用超媒体链接时不使用application / xml作为媒体类型。他们都没有说明为什么除了通用语句之外 - 没有链接关系类型的普通URI不会将URI的语义传达给客户端。
根据我的理解，建议您定义自己的自定义媒体类型并让客户端了解如何阅读它。但是，如果知道连接到我的服务的客户端永远不会是浏览器，那重要吗？我不能在应用程序/ xml类型的响应中公开这些链接吗？
我希望有人可以详细说明这一点。
答案 0 :(得分：6)
您不必使用自定义媒体类型。实际上，REST试图阻止人们创建过于特定的媒体类型。理想的是媒体类型应该传达语义信息，但不是特定于任何特定服务。
application / xml的一个问题是它没有链接外观的标准定义。是吗
<Link rel="foo" href="/foo">
或者是
<foo href="/foo">
或其他一些变种？您的客户如何知道如何在不使用“带外”知识的情况下识别文档中存在哪些链接？ “带外”知识是您想要避免的，因为它是导致客户端在服务器进行更改时中断的原因，而客户端无法保护自己免受带外知识的更改。
application/xml的另一个问题是它不包含元素和属性层次结构之外的语义。语义必须由媒体类型或链接关系传达。如果使用application/xml，则必须使用链接关系告诉客户端如何使用该文档。
在链接关系和媒体类型中传达语义之间可以有一个很好的平衡。但说实话，这个行业正试图弄清楚这种平衡究竟是什么，并且有很多人对这个主题有不同的看法。
我建议查看application/hal+xml。它与通用XML最接近，但定义了链接语义。
答案 1 :(得分：4)
以下是我能提出的最佳答案......我最近联系了菲尔丁博士来证实我的理解，但尚未得到答复。如果他对我大喊大叫，我会对它进行编辑。
我怀疑，正如Darrel Miller alluded to，目标应该是避免创建过于具体的类型 - 毕竟，它有been said：
REST API永远不应该具有重要的“类型”资源 客户。
我觉得互联网上关于超媒体的大部分内容与REST有关，基本上违反了这一原则并引导人们走错方向 - 因为他们引入了非常具体的“限定词”（我将参考它们）他们的资源。
您会看到application/vnd.com.foo.bar+xml或application/vnd.com.example.thing+json之类的内容 - 有些人已经决定不使用类型本身，而是使用参数，例如application/xml; someKey=someValue - 在我看来，这与资格不同。对我来说，这是一个类型的资源。
text/html是超文本的缩影，原因是 - 浏览器有一个处理指令，用于理解这种媒体类型。不仅仅是渲染和布局，而是强健的交互先例由HTML规范设置（例如，锚标签导致检索，表单可以触发提交和编码等），因此这个非常通用，高度强大的超媒体类型允许我们今天使用的所有网页都存在，而浏览器和提供它们的服务器之间没有任何耦合 - 唯一需要的是了解HTML作为内容类型。
这对API意味着什么？这意味着创建特定于某些资源的内容类型，某些特定的URI（或它们的集合）并不能很好地使用超媒体，并且可能意味着您具有REST试图避免的那种客户端 - 服务器耦合。这也意味着application/xml等是贫血的 - 他们有解析指令但没有处理指令。精心设计的REST API将具有更通用的超媒体类型，不是为特定资源创建的，而是为了明确定义潜在客户必须理解的处理指令才能参与。
有趣的 - 而且可能是有争议的 - 事情是text/html已经有很多 - 为什么不使用它？事实上我们的API消费者想要的不是HTML（例如他们认为JSON或XML格式是灵丹妙药），这实际上是由于对于拥有超媒体驱动的应用程序引擎意味着什么的固有误解 - 即它的处理指令是表示应该是相当通用的。当然，您可以使用XML执行此操作，只需让您的API定义一组清晰的元素及其含义即可。关于使用HTML的部分只是为了说明一点。