架构之:REST 和 HATEOAS
简介
我们知道 REST 是一种架构方式,它只是指定了六种需要遵循的基本原则,但是它指定的原则都比较宽泛,我们需要一种更加具象的约束条件来指导我们的编码。这就是 HATEOAS。
HATEOAS 简介
REST 的英文全称是 REpresentational State Transfer,表示的是状态的转移。而 HATEOAS 的全称是 Hypertext As The Engine Of Application State,表示使用超文本作为应用程序的状态。这样两者就关联起来了。HATEOAS 指定了状态的表现形式。
超文本就是链接,在 HATEOAS 的规则下,所有的资源请求都是需要带上链接的,这些链接表示可以对该资源进行的下一步操作。并且,这些链接是动态变化的,根据请求资源的不同而不同。所以,如果你的架构实现了 HATEOAS 风格的话,可以继续减少 client 和 server 端的接口依赖关系。因为所有可以进行的操作都已经放在返回资源的超链接中了。
我们举个例子,还是请求 students 的例子,假如我们请求:
那么返回的 json 可能是下面这样子的:
可以看到返回的信息包含 student 本身的信息和相关的 links 信息,里面含有 Student 的 school 信息。客户端可以通过返回的 links 继续向下获取更多的信息。
如果我们访问另外一个 student,看下返回结果有什么不同:
那么返回的 json 可能是下面这样子的:
看到有什么不同了吗? 这次学生的 age=20 ,所以拥有的选举的权限,这次在我们的 links 里面多了一个 vote 链接。
links 会根据资源的不同发送变化,客户端不需要知道任何服务器端的逻辑,每个请求都包含了所有可以继续执行的操作,从而让客户端和服务器端彻底解耦。
在现实世界中,当您访问一个网站时,您会点击它的主页。它提供了一些快照和网站其他部分的链接。您单击它们,然后您将获得更多信息以及与上下文相关的更多相关链接。
类似于人与网站的交互,REST 客户端访问初始 API URI 并使用服务器提供的链接动态发现可用操作并访问所需的资源。客户不需要事先了解服务或工作流中涉及的不同步骤。此外,客户端不再需要对各种资源的 URI 结构进行硬编码。 HATEOAS 允许服务器在不中断客户端的情况下随着 API 的发展进行 URI 更改。
HATEOAS 的格式
HATEOAS 有两个比较重要的格式,分别是 RFC 5988 (web linking) 和 JSON Hypermedia API Language (HAL)。
他们稍有不同,但是原理是大同小异的。感兴趣的朋友可以自行查阅。
HATEOAS 的 Spring 支持
人民需要什么,Spring 就造什么。同样的,对于 REST+HATEOAS 这种优美组合,怎么能够少得了 Spring 的身影呢?
Spring 推出了 Spring HATEOAS 来实现这一功能。最新的版本是 1.3.0,如果你使用的 Spring boot,那么使用起来将会更加的简单,引用下面的 XML 就可以了:
如果是非 Spring boot 环境,则可以这样引用:
在 Spring HATEOAS 中提供了一系列非常有用的特征来帮助我们创建 Link,从而减轻我们的工作。有关 Spring HATEOAS 的具体内容,我们会在后面的文章中详细讲解。
总结
如果你使用的 REST 架构,那么配合上 HATEOAS 规则应该就是最好的组合。祝你成功。
本文已收录于 http://www.flydean.com/03-rest-hateoas/
最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧等你来发现!
版权声明: 本文为 InfoQ 作者【程序那些事】的原创文章。
原文链接:【http://xie.infoq.cn/article/dbee3522fee003a81db09b71d】。文章转载请联系作者。
评论