什么是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中，很难在回到之前的方式了。