RESTful Web 服务：尝试使用自定义 XML 实现 HATEOAS
我正在开发一个企业系统，该系统将在移动客户端和中央服务器之间利用 RESTful Web 服务。可以说，尽可能地休息。
我的问题涉及 HATEOAS（超媒体作为应用程序状态引擎）以及在 HTTP 响应正文中使用自定义 xml。
该系统永远不会被公共客户端使用，但我喜欢 HATEOAS 的想法，即以后能够修改服务器端资源分配模式，而无需独立重新配置每个客户端。如果我们决定由于扩展问题需要将服务器功能分布在多个物理设备上，没问题，这将反映在客户端（或在客户端指示下的服务器）创建新资源时生成的 URI 中。
我们的业务领域非常具体且不寻常。因此，我想在整个 Web 服务中对 HTTP 响应实体主体使用自定义 XML，并且客户端将从 xml 中解析资源 URI，以便随时了解在修改其自己的应用程序状态时可以使用的资源位置。我知道这“破坏”了 HATEAOS 的 H 部分。
例如，当客户端将事务 POST 到服务器进行处理时，服务器可能会在 201 HTTP 响应正文中包含以下 xml 片段（作为较大 xml 文档的一部分）。服务器还将通知客户端新创建的事务资源本身的 URI，但这可能只包含在 Location HTTP 标头中。
<resulturi>http://resultserver/results/1234.xml</resulturi>
这有很糟糕吗？使用此服务的客户端几乎不可能是基于浏览器的。与在 xml 中以纯文本形式传递 uri 相比，超媒体还有哪些优势？
我想我可以使用 XHTML，但是我们移动平台上的解析器使用 POX 效率更高。
I am working on an enterprise system that will utilise a RESTful web service between mobile clients and a central server. As RESTful as possible, let's say.
My question relates to HATEOAS (hypermedia as the engine of application state), and the use of custom xml in HTTP response bodies.
This system will never ever be used by public clients, but I like the HATEOAS idea of being able to modify the server-side resource allocation pattern later without having to reconfigure each of the clients independently. If we decide that due to scaling issues we need to spread the server function over multiple physical boxes, no problem, this will be reflected in the URIs that are generated when a client (or the server under instruction from a client) creates a new resource.
Our business domain is highly specific and unusual. As such, I would like to use custom XML for HTTP response entity bodies throughout the web service, and the client will parse resource URIs out of the xml in order to stay informed of resource locations that it can use when modifying its own application state. I know that this 'breaks' the H part of HATEAOS.
e.g. when a client POSTs a transaction to the server for processing, the server might include the following xml fragment in the 201 HTTP response body (as part of a larger xml document). The server would also inform the client of the URI for the newly created transaction resource itself, but this would probably only be included in the Location HTTP header.
<resulturi>http://resultserver/results/1234.xml</resulturi>
Is this so bad? There is very little chance that the clients using this service will ever be browser based. What are the other advantages of hypermedia over delivering the uris as plain text within xml?
I guess I could go to XHTML, but the parser on our mobile platform is much more efficient with POX.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
通过在 resulturi 中返回 url 所做的事情实际上已经是超媒体了。唯一的问题是您需要一个媒体类型来告诉客户端响应的格式如何，以便它可以以可预测和记录的方式解析 URL。
选项 1：
创建您自己的媒体类型，例如 vnd.yourcompany.Resource+xml。通过这样做，您表明媒体类型可以由 xml 解析器解析，但它遵循您公司定义的一些特殊规则。此时，您可以使用任何您想要的标准来定义超媒体链接（请参阅 这个问题）。这样做的一个很好的优点是，如果在 6 个月内您决定需要对 XML 格式进行重大更改，您可以创建 vnd.yourcompany.ResourceV2+xml，并且只要您足够聪明，可以使用接受-在旧客户端上，您可以通过使新客户端应用程序接受新格式来顺利地将新格式与旧格式并排引入。
选项2：
我对这个选项只是半认真的态度，但我已经考虑过推动一种名为 application/hyperxml+xml 的新媒体类型。该文档将遵循与 application/xml 相同的规则，但也会使用 XLink超媒体。这将使使用 javascript 解析 XML 文档的人们也能够以标准化的方式利用超媒体。
选项 3：
使用 XHtml。我不明白为什么你的解析器在处理 Xhtml 时出现问题，但我相信你的话。
What you are doing by returning an url in resulturi is effectively hypermedia already. The only problem is that you need a media-type that tells the client how the response is formatted so that it can parse the urls out in a predictable and documented way.
Option 1:
Create your own media type like vnd.yourcompany.Resource+xml. By doing this you are stating that the media type can be parsed by an xml parser, but it follows some special rules that are defined by your company. At this point you can use whatever standard you want for defining hypermedia links (see this question). One nice advantage of this is that if in 6 months you decide you need to make a breaking change to the format of your XML you can create a vnd.yourcompany.ResourceV2+xml and as long as you were smart enough to use the accept-header on your old clients, you can smoothly introduce the new format side by side with the old one by making new client applications accept the new format.
Option 2:
I'm only half serious about this option, but I have considered pushing for a new mediatype called application/hyperxml+xml. The document would follow the same rules as application/xml but would also make use of XLink for hypermedia. This would allow people who are using javascript to parse the XML document to also take advantage of hypermedia in a standardized way.
Option 3:
Use XHtml. I don't understand why your parser has problems with Xhtml, but I'll take your word for it.
无论底层标记语言如何，RESTful 服务器处理请求都需要两条重要信息：媒体类型和 URI。假设给定 URI 的媒体类型会引入客户端-服务器耦合。例如，它会阻止同一 URI 提供两种不同类型的媒体类型。
XML 并不是设计超媒体格式时的唯一选择。查看 Sun Cloud API，它定义了 超文本驱动 基于 JSON 的 REST API（尽管它似乎不使用媒体）键入及其超链接）。从这种方法转向将媒体类型与超链接相结合的方法并不困难。
例如，您可以定义一个名为 Link 的 JSON 数据结构，如下所示：
There are two important pieces of information your RESTful server will need to process requests, regardless of the underlying markup language: a media type and a URI. Assuming a media type for a given URI would introduce client-server coupling. It would, for example, prevent the same URI from ever serving two different kinds of media type.
XML isn't the only option when designing hypermedia formats. Check out the Sun Cloud API, which defines a hypertext-driven REST API based on JSON (although it appears to not use media type with its hyperlinks). It's not difficult to go from this approach to one that combines media types with hyperlinks.
For example, you could define a JSON data structure called Link that looks like this;
超媒体不需要 HTML，甚至不需要完全限定的 URI。如果您的媒体类型定义了将响应的某些元素转换为可取消引用的资源的规则，那么您就拥有了超媒体。
上面的示例与关于如何取消引用结果元素内容的媒体类型规则相结合，是超媒体，其方式与以下相同：
带有一条在前面添加基本 http URI 的规则。下面的示例也是如此，其中 http 字符串可取消引用的事实可能会被隐式保留。
然而，虽然它们都是超媒体并满足该限制，但如果可能的话，我反对创建自己的新超媒体生产规则和标签，而只是重用现有的规则和标签。与最后一个示例相比，第一个示例使用户不太清楚该元素表示超链接资源。
Hypermedia does not require HTML or even fully qualified URIs for that matter. If your media type defines a rule for turning some elements of the response into de-referenceable resources then you have hypermedia.
The above example, combined with a media type rule on how to dereference the contents of the result element is hypermedia in the same way that:
is with a rule to prepend the base http URI. So is the example below where the fact that the http string is dereferencable may be left implicit.
However, while they are all hypermedia and meet that constraint, I would argue against creating your own new hypermedia production rules and tags if at all possible and just re-use existing ones. The first example makes it less obvious to the user that this element represents a hyperlinked resource than the last example.
我建议不要手动编码这些超链接，而是使用为您创建这些超链接的工具。
面向交互的编程是创建这些交互（超链接）的好方法。请点击此链接，该技术对我们有用 http://www.masterkube.com/hateoas_technology.html
I would suggest that rather than hand code these hyperlinks, use a tool which creates those hyperlink for you.
Interaction oriented programming is a good method to create these interactions (hyperlinks). Please follow this link this technology worked for us http://www.masterkube.com/hateoas_technology.html
至少（即使您不执行任何其他操作），您应该将 URL 放在 中XLink 属性而不是元素内容：
XML 处理器能够本地解析并遵循这些 URI。作为一般规则，不可翻译或永远不可能有子元素的文本应位于属性中以强制实施此类限制。
但除此之外，请按照其他人的建议进行操作并定义您的媒体类型，以便客户能够理解其含义。
At a very minimum (even if you do nothing else), you should put your URL in an XLink attribute instead of the element content:
XML processors are able to parse and follow these as URIs natively. As a general rule, text which is not translatable or could never have sub-elements should be in an attribute to enforce such restrictions.
But beyond this, do what others have suggested and define your media type so that the meaning can be understood by clients.