内容简介:HATEOAS是举例来说,假设向API发起一次get请求,获取指定订单的资源表述(representation),那么它应该长得像这样:
要点
- HATEOAS是 Hypertext As The Engine Of Application State 的缩写。在 Richardson Maturity Model 中, 它是REST的最高级形态
- 单页应用正越来越受到欢迎,前后端分离的开发模式进一步细化了分工、消除了瓶颈,但同时也引入了不少重复的工作,例如一些业务规则在后端必须实现的情况下,前端也需要再实现一遍已获得更好的用户体验。HATEOAS虽然不是唯一消除这些重复的方法,但作为一种架构原则,它更容易让团队找到消除重复的“套路”
什么是HATOEAS
HATEOAS是 Hypertext As The Engine Of Application State 的缩写。采用Hypermedia的API在响应(response)中除了返回资源(resource)本身外,还会额外返回一组Link。 这组Link描述了对于该资源,消费者(consumer)接下来可以做什么以及怎么做。
举例来说,假设向API发起一次get请求,获取指定订单的资源表述(representation),那么它应该长得像这样:
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: application/hal+json;charset=UTF-8 Transfer-Encoding: chunked Date: Fri, 05 Jun 2015 02:54:57 GMT { "tracking_id": "123456", "status": "WAIT_PAYMENT", "items": [ { "name": "potato", "quantity": 1 } ], "_Links": { "self": { "href": "http://localhost:57900/orders/123456" }, "cancel": { "href": "http://localhost:57900/orders/123456" }, "payment": { "href": "http://localhost:57900/orders/123456/payments" } } }
- 理解Link中的“self”的消费者知道使用get方法访问其“href”的uri可以查看该订单的详细信息
- 理解Link中的“cancel”的消费者知道使用delete方法访问其“href”的uri可以取消该订单
- 理解Link中的“payment”的消费者知道使用post方法访问其“href”的uri可以为该订单付款
REST是目前业界相当火热的术语,似乎发布的API不带个REST前缀,你都不好意思和别人打招呼了。 然而大部分号称REST的API实际上并没有达到 Richardson成熟度模型 的第三个级别:Hypermedia。 而REST的发明者Roy Fielding博士更是直言 HATEOAS是REST的前提, 这不是一个可选项,如果没有Hypermedia,那就不是REST。 (摘自Infoq对Fielding博士的第二段访谈)
那么HATOEAS带来了什么优势?
一个显而易见的好处是,只要客户端总是使用Link Rel来获取URI,那么服务端可以在不破坏客户端实现的情况下实现URI的修改,从而进一步解耦客户端和服务端。
另一个容易被忽视的优势是它可以帮助客户端开发者探索API,Links实际上提示了开发者接下来可以进行何种业务操作,开发者虽然精通技术,但往往对于业务不甚了解,这些提示可以帮助他们理解业务,至少是一个查询API文档的好起点。想象一下,如果某个API的响应中多了一个新的Link,敏感的开发者可能就会询问这个Link是用来做什么的,是一个新的特性吗?虽然看起不起眼,但这往往使两个团队的成员沟通起来更容易。
单页应用和HATEOAS
在过去的几年里,WEB开发技术发生了很多重大的变革,其中之一就是单页应用,它们往往能带来更平滑的用户体验。在这一领域,分工进一步细化,前端工程师专精客户端程序构建和HTML、CSS等效果的开发,后端工程师则更偏重高并发、DevOps等技能,大部分特性需要前后端工程师配合完成。或许有人会质疑,为什么不是全栈工程师?诚然,如果一个人就能端到端的交付特性,那自然会减少沟通成本,但全栈工程师可不好找,细化分工才能适应规模化的开发模式。继Ajax之后,单页应用和前后端分离架构进一步催生了大量的API,我们急需一些方法来管理这些API的开发和演进,而HATEOAS应该在此占有一席之地。
在摸索中前进,自由地重命名你的资源
我们常说在敏捷开发中,应该拥抱变化。所以敏捷开发中推崇重构、单元测试、持续集成等技术,因为它们可以使变化更容易、更安全。HATOEAS也是这样一种技术。想象一下,在项目初始阶段,团队对业务的理解还不深入,很有可能会得出错误的业务术语命名,或者业务对象的建模也不完全合适。反映在API上,可能你希望能够修正API的URI,在非HATOEAS的项目中,由于URI是在客户端硬编码的,即使你把它们设计的非常漂亮(准确的HTTP动词,以复数命名的资源,禁止使用动词等等),也不能帮助你更容易地修改它们,因为你的重构需要前端开发者的配合,而他/她不得不停下手头的其他工作。但在采用了HATEOAS的项目中,这很容易,因为客户端是通过Link来查找API的URI,所以你可以在不破坏API Scheme的情况下修改它的URI。当然,你不可能保证所有API的URI都是通过Link来获取的,你需要安排一些Root Resource,例如 /api/currentLoggedInUser
,否则客户端没有办法发起第一次请求。
HTTP/1.1 200 OK Path: /api/currentLoggedInser (1) { …… //omitted content "_Links": { (2) "searchUserStories": { "href": "http://localhost:8080/userStories/search{?page, size}" }, "searchUsers": { "href": "http://localhost:8080/users/search{?page, size, username}" }, "logout": { "href": "http://localhost:8080/logout" } } }
- Root Resource,它们是API的入口,客户端通过他们浏览当前用户有哪些资源可以访问,你可以定义多个Root Resource,并确保它们的URI不会改变
- Link引入的URI可以自由地变化,可能是因为需要重命名资源,也可能是需要抽取出新的服务(域名变化)
消除重复的业务规则校验实现,更容易得适应变化
经验告诉我们,不能相信客户端的请求,所以在服务端我们需要根据业务规则校验当前的请求是否合法。这样确保了业务正确,但当用户发起了请求后才告诉他们请求失败,有时候是一件令人沮丧的事情。为了用户体验,可能会要求某些组件根据业务规则展示。例如,对于某个业务对象,要求编辑按钮只在当前用户可以编辑的情况下才展示。在传统的服务端渲染架构下,一般都可以复用校验的代码,而在单页应用中,往往由于技术栈不同,代码无法直接共用,业务规则在前后端都分别实现了一次。例如,在我们最近的一次项目中,前后端分别实现了如下规则:
给定一个用户故事,
只有它的作者才能编辑它
服务端通过在用户故事的API中暴露作者帮助前端完成编辑按钮的有条件渲染。
HTTP/1.1 200 OK Path: /api/userStories/123 { "author": "john.doe@gmail.com" (1) }
- 与当前用户比较判断是否渲染编辑按钮
但如果规则发生变化,前后端都需要适应这一改变,所以我们用HATEOAS重构了一下:
HTTP/1.1 200 OK Path: /api/userStories/123 { "author": "john.doe@gmail.com", "_links": { "updateUserStory": { "href": "http://localhost:8080/api/userStories/123" } (1) } }
- 现在前端会根据
updateUserStory
link是否出现来验证当前用户是否具有编辑用户故事的能力
后来业务规则变为 除了作者之外,系统管理员也可以编辑用户故事
,这时候只需要后端去响应这个变化就行了。你可能会质疑,通过为用户故事暴露一个 isCurrentLoggedInUserAvailableToUpdate
的计算属性也可以做到。没错,HATOEAS并不是唯一的办法,但作为一种架构约束,团队会自然而然地想到它,而计算属性则要求团队成员有更强的抽象技能。
总结
HATEOAS提倡在响应返回Link来提示对该资源接下来的操作。这种方式解耦了服务端URI,也可以让客户端开发者更容易地探索API。最后,通过Link来判断业务状态,还能有效地消除单页应用中的业务规则重复实现。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- go语言实战教程:Redis实战项目应用
- 单页应用的HATEOAS实战
- Vue应用框架整合与实战
- Spark综合使用及电商案例实战精析-Spark商业应用实战
- Spark Streaming--应用与实战(一)
- Spark Streaming--应用与实战(四)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
人机交互:以用户为中心的设计和评估
董建明、傅利民、[美]沙尔文迪 / 清华大学出版社 / 2003-9-1 / 28.00
本书综述部分介绍了与“用户为中心的设计和评估”方法相关的背景知识及发展概况。其后,分3篇分别介绍了解用户、用户界在设计和可用性评估的内容及一些相关的研究专题。最后,第11章讨论了在组织中实施以用户为中心的设计的专题。本书主要面向的读者包括:软件或网站的设计人员。同时本书也可成为“现代人因工程学”及“以用户为中心的设计”的教材,还可作为软件或网站公司经理的提高用户满意度或提升公司形象的手册。一起来看看 《人机交互:以用户为中心的设计和评估》 这本书的介绍吧!