为什么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

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

你可能感兴趣的:(为什么HATEOAS?)