在RESTFul API中使用HATEOAS的好处

Sun公司的Craig McClanahan给为什么现有“REST”API没有真正使用RESTful服务中的“超媒体即应用状态引擎（HATEOAS）”提供了答案。他从最近参与的Sun云计算API  设计中举例说明了这样做的好处。

我们一开始假设服务只能发布 一个众所周知的URI（返回一个包含调用者可访问的云资源表示[representation]的 云表示，它也可以是一个URI链接）。通过检查这些表示就可以发现整个系统中的其他每个URI（包括所有完成状态改变的URI）。

Craig建议通过资源图来让超媒体给客户端提供指导；通过把资源及其关系描述成指向它们的超媒体，可以让交互式的Web应用完成用户可以完成的工作；让客户端有效地浏览资源表示，驱动应用状态的改变。他认为，这样设计的好处是：

• 降低客户端编码错误。大约90%的错误出现在为服务器构造正确URI的过程中。典型错误是遗漏路径片断（Path Segment），以错误的顺序获取它们，或者忘记URL编码的东西。
• 减少无效的状态转换调用。[……]举个例子[出自云计算API……]，你只有“部署”了虚拟机（VM），才能去“启动”它。服务器知道URI发起了每次状态改变（通过POST），但是VM的表示只罗列出了由当前状态可以有效转换的那些状态转变的URI。
• 无需破坏客户端就可进行细粒度演变。每次在编写REST API客户端时，都会对系统能做什么进行一些假设。但是，如果你仅记录那些“需要知道的表示内容”，再加上那些不会破坏先前行为的服务器端规定，你就能在不破坏所有客户端的情况下快速演变API，或者在服务器上同时支持API的多个版本。

Marc Hadley在他的帖子中对讨论进行了补充，提到可以使用WADL来进行描述……

……一组URI和URI模板，依赖客户端去构建URI来访问它们需要的资源，云计算API只发布一个“根”URI，并记录下客户端可以在表示中哪个位置找到用来遍历服务的其他URI。

他描述了一种对Web应用进行文档化的可能方式，如Sun云计算API使用WADL，并通过例子解释了其想法。

1. 使用资源类型描述每种资源，
2. 对表示进行参数化，以标识内嵌于它们中的链接
3. 定义每个内嵌于链接标识中的资源类型。

请阅读原贴，并可在rest讨论组中进行讨论。

查看英文原文：Advantages Of (Also) Using HATEOAS In RESTFul APIs