在 RESTFul API 中使用 HATEOAS 的好处

阅读数:6502 2009 年 4 月 24 日

话题:SOAREST云计算DevOps架构

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