为什么HATEOAS？

来自于一两个简单的问题，总结如下：

    * 如果超媒体作为应用程序状态引擎：Hypermedia as the Engine of Application State (HATEOAS) 这么酷，为什么没有被今天的更多REST API使用。
    * 伴随着适应变化能力的长期好处，有没有什么短期的回报？

我十分清楚你为什么会问这些问题。。。我在之前也有这样的疑问。在过去几年，我设计过很多REST的API，直到我最近设计的一个才发生了改变，我使用“典型”的方式设计和写文档，描述程序的URI结构并且让客户端找出何时发送什么。我最近的工作是参与设计SUN云计算API去控制虚拟机之类的。作为附加工作，我化很大精力在编写客户端API的多种语言（Ruby，Python,Java...)绑定，所以我获得了针对这个API进行编程的非常直接的第一手的感受。

我们从假定这些服务只公布 一个 对外发布的URI（返回一个云表述包含所要表述的内容，并且/或者链接到所表述内容的URI，所有的可以被当前用户访问的云资源）。整个系统中的所有其他 URI（包含所有会发生状态改变的）都是从分析这些表述中获得的。即使还只是在早期，我也能看到我们从采取这种方法上获得的一些重要的，务实的，短期的好处。

    * 降低客户端编程错误。 回顾所有我或者我参与设计的REST客户端接口，大约90%的bug出现在构建正确的服务器交互URI上。典型的错误有漏掉部分路径，错误的路径顺序或者忘记了URL编码等。当服务器在任何情况下都给你了正确的URI时，所有这些都会消失。
    * 降低无效的状态迁移请求。 当客户端决定什么时候请求什么URI时，就有风险会尝试发起在服务器端资源的当前状态无效的请求。我的情况下的一个例子。。。除非你“deploy(部署)”了一个虚拟机（VM）否则是不能"start(启动)"他的。服务器知道发起每个状态改变的URI（通过POST），但是虚拟机列表的表述（representation，不理解的看REST的文档，可以简单理解为这一时刻返回的内容）只有当前状态下有效的状态变迁请求的URI。这使客户端非常容易理解“start”一个还没有“deploy”的虚拟机是不被允许的，因为虚拟机的表述里面就没有对应的URI。
    * 渐进试改进并且不破坏（非必要的）旧客户端。 在任何一个给定时间，任何REST API的客户端都是基于系统能做什么的 一些 假设编程的。但是，如果确定一个限制--“只关注你所知道的表述的这些方面”，加上服务器端严格控制后加的功能不破坏之前的行为，你可以合理快速的改进 API而不破坏所有客户端，否则你不得不在你的服务器上同时维护多个版本的API。你不需要花费多年等待回报：-）特别是使用版本（在WSDL中）管理表述的格式的SOAP，你不得不在每次修改时处理和客户端相关的麻烦。

现在陶醉在HATEOAS中，很难在回到之前的方式了。

-----------------------------------------------------------------------华丽的分割线-------------------------------------------------------------------------

原文章地址http://blogs.sun.com/craigmcc/entry/why_hateoas

发现很不错就翻译了，翻译的不好，多包涵。

评论

1 楼 kiol 2009-12-16  

不知道这种方式能否可以作为实现业务流程或者工作流程的一种方法,和传统的工作流和业务流是否冲突?相比又如何呢?