RESTful Web服务:尝试使用自定义XML实现HATEOAS

我正在开发一个企业系统,它将在移动客户端和中央服务器之间使用RESTful Web服务.尽可能使用RESTful,让我们说.

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

该系统永远不会被公共客户端使用,但我喜欢HATEOAS的想法,即能够在以后修改服务器端资源分配模式,而无需独立地重新配置每个客户端.如果我们决定由于扩展问题我们需要在多个物理盒上扩展服务器功能,没问题,这将反映在客户端(或来自客户端的指令下的服务器)创建新资源时生成的URI中.

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

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

http://resultserver/results/1234.xml

这真糟糕吗？使用此服务的客户端几乎不可能基于浏览器.超媒体在xml中以纯文本形式提供uris的其他优点是什么？

我想我可以去XHTML,但我们的移动平台上的解析器使用POX更有效率.

你在resulturi中返回url所做的事实上已经是超媒体了.唯一的问题是,您需要一种媒体类型,告诉客户端如何格式化响应,以便它可以以可预测和记录的方式解析URL.

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

选项2:我对这个选项只有一半认真,但我考虑过推动一种名为application/hyperxml + xml的新的mediatype.该文档将遵循与application/xml相同的规则,但也会使用XLink进行超媒体.这将允许使用javascript解析XML文档的人也以标准化方式利用超媒体.

选项3:使用XHtml.我不明白为什么你的解析器有Xhtml的问题,但我会接受你的话.