我目前正在设计一个纯粹面向资源的企业服务。在阅读了几篇博客、书籍等之后。我相信带有超媒体链接的 REST 是要走的路。
但是，所有这些博客和书籍都说的一件事是在响应中使用超媒体链接时不要使用 application/xml 作为媒体类型。除了通用声明之外，他们都没有说明原因 - 没有链接关系类型的普通 URI 不会将 URI 的语义传达给客户端。
据我了解，这是一种推荐的方法来定义您自己的自定义媒体类型并让客户知道如何阅读它。但是如果知道连接到我的服务的客户端永远不会是浏览器，这有关系吗？我不能在我的响应中使用 application/xml 类型公开这些链接吗？
我希望这里有人可以详细说明这一点。
您不必使用自定义媒体类型。事实上，REST 试图阻止人们创建过于具体的媒体类型。理想的情况是媒体类型应该传达语义信息，而不是特定于任何特定服务。
application/xml 的一个问题是它对链接的外观没有标准定义。是吗
<Link rel="foo" href="/foo">
或者是
<foo href="/foo">
或其他一些变体？您的客户如何知道如何在不使用“带外”知识的情况下识别文档中存在哪些链接？“带外”知识是您要避免的，因为它会导致客户端在服务器进行更改时中断，并且客户端无法保护自己免受带外知识的更改。
另一个问题application/xml是它除了元素和属性的层次结构之外不包含任何语义。语义要么必须通过媒体类型或链接关系来传达。如果您使用application/xml，那么您必须使用链接关系来告诉客户端如何使用该文档。
在链接关系和媒体类型中传达语义之间可以有一个很好的平衡。但老实说，这个行业正在试图弄清楚这种平衡到底是什么，并且有很多人对这个问题有不同的看法。
我建议查看application/hal+xml。它最接近通用 XML，但定义了链接语义。
这是我能想到的最佳答案……我最近联系了菲尔丁博士以验证我的理解，但尚未收到回复。如果他对我大喊大叫，我会修改它。
我怀疑，正如 Darrel Miller 所暗示的那样，目标应该是避免创建过于具体的类型——毕竟，有人说过：
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 的部分只是为了说明一点。
有抱负的 REST API，即使有一组丰富的超链接来表达通过资源的状态转换，也可能——而且似乎最常见——无法实现 REST 真正涉及的那种可扩展的、长期存在的架构风格。