xml - RESTful 网络服务 : trying to achieve HATEOAS with custom XML

Question

我正在开发一个企业系统，该系统将在移动客户端和中央服务器之间使用 RESTful Web 服务。比方说，尽可能 RESTful。

我的问题涉及 HATEOAS(超媒体作为应用程序状态的引擎)，以及在 HTTP 响应主体中使用自定义 xml。

这个系统永远永远不会被公共(public)客户端使用，但我喜欢 HATEOAS 的想法，它可以在以后修改服务器端资源分配模式，而不必独立地重新配置每个客户端。如果我们决定由于缩放问题我们需要将服务器功能分布在多个物理盒子上，没问题，这将反射(reflect)在客户端(或在客户端指令下的服务器)创建新资源时生成的 URI 中.

我们的业务领域非常具体且不同寻常。因此，我想在整个 Web 服务中为 HTTP 响应实体主体使用自定义 XML，并且客户端将从 xml 中解析资源 URI，以便随时了解它在修改自己的应用程序状态时可以使用的资源位置。我知道这会“破坏”HATEAOS 的 H 部分。

例如当客户端将事务 POST 发送到服务器进行处理时，服务器可能会在 201 HTTP 响应正文中包含以下 xml 片段(作为更大的 xml 文档的一部分)。服务器还将通知客户端新创建的事务资源本身的 URI，但这可能只包含在 Location HTTP header 中。

<resulturi>http://resultserver/results/1234.xml</resulturi>

这这么不好吗？使用此服务的客户端几乎不可能是基于浏览器的。与在 xml 中以纯文本形式提供 uris 相比，超媒体还有哪些其他优势？

我想我可以使用 XHTML，但我们移动平台上的解析器使用 POX 效率更高。

Answer 1

您通过在 resulturi 中返回一个 url 所做的实际上已经是超媒体了。唯一的问题是您需要一种媒体类型来告诉客户端响应的格式，以便它可以以可预测和记录的方式解析 url。

选项 1:创建您自己的媒体类型，例如 vnd.yourcompany.Resource+xml。通过这样做，您声明媒体类型可以由 xml 解析器解析，但它遵循您公司定义的一些特殊规则。此时您可以使用任何您想要的标准来定义超媒体链接(参见 this 问题)。这样做的一个好处是，如果在 6 个月后您决定需要对 XML 格式进行重大更改，您可以创建一个 vnd.yourcompany.ResourceV2+xml，只要您足够聪明，可以使用 accept-旧客户端上的 header ，您可以通过让新客户端应用程序接受新格式来顺利地同时引入新格式和旧格式。

选项 2:我对这个选项只是半认真，但我考虑过插入一种名为 application/hyperxml+xml 的新媒体类型。该文档将遵循与 application/xml 相同的规则，但也会使用 XLink。对于超媒体。这将使使用 javascript 解析 XML 文档的人也能够以标准化的方式利用超媒体。

选项 3:使用 XHTML。我不明白为什么您的解析器会出现 Xhtml 问题，但我会相信您的话。