BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

与HAL的创造者Mike Kelly的一次访谈

| 作者 Mike Amundsen 关注 9 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2015年3月3日. 估计阅读时间: 13 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

为Web设计、实现和维护API不仅仅是一项挑战;对很多公司来说,这是一项势在必行的任务。本系列 将带领读者走过一段旅程,从为API确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在Web上维护公共API。沿途将会有对有影响力的人物的访谈,甚至还有API及相关主题的推荐阅读清单。

这篇 InfoQ文章是 Web API从开始到结束系列文章中的一篇。你可以在这里进行订阅,以便能在有新文章发布时收到通知

Mike Kelly是一位软件企业家,也是Stateless的创建人,Stateless是一家为各个企业提供API顾问服务,帮助他们制订策略、进行设计,并且应对实现方面的挑战的公司,Kelly目前与他的妻子和三个孩子定居在London郊外的温彻斯特小城。从年轻时起,Kelly就活跃在web这一领域中,他在API与REST社区中也是众所周知的活跃人士。

2011年,他发布了超文本应用语言(HAL)这种用于API的媒体类型。从那时起,HAL就成为了API超媒体格式方面最耀眼的明星,而Mike Kelly也被公众视为在Web API方面的一位领导专家。他并不经常参与各种公众活动,但最近却破例参加了在密歇根州的底特律举办的2014 API-Craft大会,并且在会议上举办了一次演讲,谈论了HAL的现状以及超媒体和API在未来的应用。

在那次会议后不久,我们有幸对Mike进行了一次访问,谈到了他创建HAL背后的原因,以及他在这三年来与web开发者和API社区交流的经验。

InfoQ:在2011年七月,超文本应用语言(HAL)媒体类型在IANA获得了注册。请问你创建HAL背后的动机是什么呢?

Mike当时我正在帮助一位客户设计他们的Saas产品,按照该产品的路线图设计,它们将会面临大量后端的变更,并且将影响到整个API的URL结构。我希望所设计出的API能够在应对这些变更时尽量不要受到影响,而超媒体看起来对于该产品是种理想的设计风格。

InfoQ:这么说来,其中的一个关键目标就是尽量减小“时间的推移”所带来的影响吗?

Mike不错。另外还有一个设计目标,就是尽量提升开发者上手使用这套系统的体验,因为API集成是这个产品的关键价值所在,也是销量的关键驱动力之一。对我来说,这意味着我们需要一套清晰的、容易获取的说明文档,并且API本身一定要易于使用。

出于以上原因,我决定创建一个API浏览器,让开发者可以随时参考并且探索这套API的应用及相关的文档,这与他们对某个web应用的探索方式差不多。因此,我需要一种通用的格式,在整套API中使用这一格式,随后就可以针对这种格式创建出API浏览器。

InfoQ:所以说HAL最初的目标就是为了解决你的某个项目中所遇到的问题。用Eric Raymond的话来说,你只是为自己“挠了挠痒”。既然HAL只是用来处理你这个SaaS产品的问题,那它又怎么会成为一种通用的格式,并且为这么多人所接受呢?

MikeHAL在那个项目中确实起到了作用,因此我将这一想法分享给了API界的同行们,让他们看看我为这个基于JSON的通用格式编写的一些示例。人们的反馈相当正面积极,甚至有一部分人已经打算在他们自己的API中使用这个还没有定稿的格式了。我因此燃起了动力,总之,我最后创建了一个网页,对这个设想进行更为详细的描述(我在此将这一设想称之为超媒体应用语言,或HAL),最终成为了一个正式的互联网标准草稿。

InfoQ:在最近几年来,不断有新的以API为中心的媒体类型被注册,而HAL是这一浪潮的带头者。你觉得这一浪潮的起因是什么?为什么新的设计不断涌现?

Mike我想这是因为人们逐渐认识到,虽然说每种API所对应的商业领域可能是完全不同的,但从架构风格的角度来看,有许多内容是相通的。我们可以从超媒体开始,将这些相通的内容映射到API的设计中,这就使我们能够开发及分享这些工具及技术,让它们去应对更广泛的问题。

InfoQ:说到“相通的内容”,HAL的设计中很重要的一点,就是它专注于消息中的“链接与资源”,并且依赖于可读的文档,对如何使用HTTP方法对这些资源进行操作加以解释。为什么你会使用这种方式设计HAL呢?

Mike我发现对于我所用过的大多数API来说,它们都需要提升开发者上手使用的体验,因为它驱动了关键的成功指标,例如API使用者的接受度与活跃度。在我看来,要实现这一点,你必须让API消息保持简洁,并且用详实的、可读的文档为开发者说明这些消息的具体细节。

InfoQ:因此你的设计依赖于一种机器可读的格式,以及一种人类可读的文档。如果让消息体包含执行一个方法所需的所有细节,例如参数、方法名称等等,又会产生怎样的结果?

Mike我认为为媒体类型添加新的特性会产生一种收益递减效果——越多不代表越好,越多的特性代表使用该种格式的客户的负担更重。HAL是我认为在超媒体设计中最平衡有效的结果。

InfoQ:在2014年早期,Amazon宣称会在它们的AppStream API中使用HAL,你是否也为Amazon进行了某些指导,帮助它们学习如何在API中使用HAL

Mike令我感到高兴的是,我没有直接参与此事。我想这是个积极的信号,说明HAL的设计与规格正在朝着正确的方向前行。使用HAL进行设计的API越来越多,已经多到难以计数了!

InfoQ:因此API社区自己选择了对HAL的使用,以及帮助处理HAL方面的相关问题。我知道你维护着一个HAL相关的邮件列表(HAL Discuss),这个列表也十分活跃。我注意到有许多人提出HAL相关的问题,或是分享在HAL方面的经验,但你本人的发帖数似乎并不多,为什么呢?

Mike由于HAL使用者社区能够积极地分享他们的经验,以及对规格的理解,因此我不再需要回答这个邮件列表中所产生的大量问题,或是给出许多建议了,这也说明了HAL正在快速发展。我觉得这是一件很好的事,因为HAL在目前的发展已经超出我了所构思的设计目标。幸运的是,我对HAL的解读及社区对它的理解和使用看起来是高度一致的。

InfoQ:我手头上并没有一张图表,但我听说在近年来各种新型API设计中,HAL是使用率最高的超媒体格式,是真的吗?你觉得产生这一结果的原因是什么?为什么HAL能够吸引这么多开发者使用?

Mike我也一样没有任何图表,但我同意HAL看起来确实是使用率最高的。我认为原因在于HAL的设计非常平衡,它引入了超媒体,但又不会过度影响JSON格式的简易性。实际上,我想以上这一点只是原因之一,另一个重要的原因,或许只是HAL在正确的时间出现在正确的地方罢了。

InfoQ:好的,我们又回到之前所讨论过的一些设计上的决策了。比方如,在HAL Discuss邮件列表中经常谈论起的某个主题,是有人认为HAL缺乏了在HTML、Siren、Collection+JSON等格式中常见的内联“形式”。有些人希望在HAL规格中加入这一特性,你对此有什么要说的吗?

Mike虽然你可以尝试为HAL加入更多动态元素,但我坚持反对这么做,因为新增加的复杂性会使得消息体的简洁性降低,从而影响到开发者上手使用的体验。而且也无法处理现实世界中的问题。

之所以有许多人希望在API消息体中加入“形式”,是因为他们需要在GUI应用中使用这一信息。但我的想法是,HTML本身已经是一个完美的表现GUI形式的超媒体格式了,它具有高度一致性,并且开发者们也非常熟悉HTML。对于那些在JSON中引入了形式的媒体类型来说,我感觉它们是在重复发明那个复杂的轮子,有事倍功半之嫌。

InfoQ:因此你还是将HAL视为一种机器与机器(M2M)之间通信的使用方式,而且你认为将这一信息内联对机器来说没有很大的用处,是吗?

Mike真要说起我对M2M中形式的使用方面的想法,我想这得专门再进行一次访谈才行!总的来说,我对此保持怀疑,而且我也没有看到有任何有力的示例(无论是理论的还是现实世界中的)能够说服我:为这一功能增加HAL的复杂性确实是值得的。

说起这一点,前一阵子我为HAL设计了一个扩展,称为HALO,其中就加入了这种动态方面的功能。人们对它很感兴趣,但老实说,我对于它的实用性并不太看好,也没有什么动力继续推动这个项目的开发。

InfoQ:在一年多之前,你创建了一个HAL RFC文档,其中的内容如今已经过期了。你是否计划重新修改这份文档呢?

Mike是的,我最近刚刚在HAL Discuss邮件列表中发送了一个请求,看看大家对于这个规格说明有没有什么最后的反馈与调整意见。如果哪位读者有任何意见希望进行分享,请提交一个pull请求!

InfoQ:从你最初发布HAL以来已经过去了三年。如果能从头再来一次,你会做出什么不同的选择吗?有哪些东西是你希望能够早点知道的呢?

Mike我对HAL目前的结果以及它一路前行的过程都感觉十分满意。

或许我应该更快地编写出HAL浏览器并更早地发布它,因为它确实“触动”了许多人的心灵。此外,我也觉得自己应该更积极地参与一些引人关注的开源web框架的早期开发过程,例如rails-api和ember.js,因为这些框架可以使用HAL这样的通用媒体类型作为它们的默认消息格式,这样一来就会使得HAL的应用更加广泛了。需要指出的是,rails与ember项目都出现了第三方的HAL类库,并且许多其它语言及框架也有第三方的HAL类库存在。

InfoQ:好的,最后一个问题了:如今每隔几个月就有一种新的格式会出现。作为这股媒体类型设计者浪潮的带头人之一,你对于那些正在考虑创建新的媒体类型的同行有什么建议吗?

Mike:我的建议就是不要想着加入太多的特性。你的规格越简短越好。让它解决你的实际问题,不要去自找麻烦。不要自作聪明,尽量使用直白的语言和简短的示例。尽早将你的设计分享给大家,让设计越来越清晰明确。最后一点,不要尝试在JSON中重新发明HTML!

关于受访者

Mike Kelly是一位软件企业家,也是Stateless的创建人,Stateless是一家为各个企业提供API顾问服务,帮助他们制订策略、进行设计,并且应对实现方面的挑战的公司,Kelly目前与他的妻子和三个孩子定居在London郊外的温彻斯特小城。他主要为伦敦及欧洲的客户提供服务。最近,他来到了密歇根州的底特律,作为一位特邀嘉宾及讲师参加了API Craft大会。他在演讲中介绍了超媒体API,以及由他设计的那套非常流行的超媒体设计,名为超文本应用语言(HAL)。

 

为Web设计、实现和维护API不仅仅是一项挑战;对很多公司来说,这是一项势在必行的任务。本系列 将带领读者走过一段旅程,从为API确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在Web上维护公共API。沿途将会有对有影响力的人物的访谈,甚至还有API及相关主题的推荐阅读清单。

这篇 InfoQ文章是 Web API从开始到结束系列文章中的一篇。你可以在这里进行订阅,以便能在有新文章发布时收到通知

查看英文原文:An Interview with HAL Creator Mike Kelly

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT