在 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