微信号:infoqchina

介绍:有内容的技术社区媒体

超媒体API引发的REST生存危机

2014-04-08 19:37 InfoQ

几周以前,软件开发者Evan Cordell在API-Craft 邮件组中引发了一场对话,就关于REST在超媒体方面的约束,与常见Web API需求之间如何存在分歧进行了讨论。


在讨论“REST的生存危机(RESTisentialcrisis)”话题的时候,Cordell注意到,经过数年之久的辩论和实践,REST风格终于开始透露出它藏得最深的秘密——超媒体约束。尽管Web证明了REST风格完美适用于人类驱动的交互,但对于它在一般性可编程Web API方面的效用的担心,在Web API社区中却似乎在不断上升。


在这场讨论中,他首先给出了REST的描述,以及在面向特定领域Web API时超媒体的制约,接下来考虑了对其他架构风格的需求,选用REST中最好的部分,并替换掉其中的一些约束,以获得不同的价值,例如有效和可靠的M2M(Machine-to-Machine)通讯。


讨论中所列出的主要担忧,涉及了不同的途径,用来应对接口随着时间推移而产生的变更。第一套解决方案要求并行运行若干API版本,甚至若干API编配以用于特定客户端体验,例如Netflix所展示的做法。其灵活性方面则需要面对设计和运营方面的重大挑战。


第二个解决方案要求预先投入更多的努力,来设计一套更易于应对变化的RESTful超媒体API,并限制对客户端的影响——就像HTML浏览器和服务器的工作和演进那样。但部分讨论参与者(特别是Web工程师Mike Kelly)对此表达了自己的担心,主要集中在实现该方案涉及的复杂度和API使用者需要承担的额外负担方面。以下是讨论摘要,包括对Evan最初帖子内容和章节标题的摘录:


1) 好的API不会发生变化

  • 考虑一下Joshua Bloch在设计公共Java API方面的经验,我们似乎可以认为,相同的规则也可以运用到可编程Web API上。

  • API是遵循外观模式的接口,面向客户端的部分不应该发生变化。然而,可以将多重或演进的实现(包括运行时数据)暴露出来,而无须改变API约定。


2) 版本管理不起作用

与“传统”API相比,“Web API”公开出来的内容要多得多。它暴露出数据;而且对于持续变化数据的大型集合,它通常还会把其当前状态公之于众。那么,当我们的领域模型拥有两个版本,它们共享部分数据子集但使用不同方式访问的时候,该如何有效的进行版本管理?这会强迫客户端发生分裂。

  • 超媒体能够帮助API演进并变得不那么脆弱,但是如果数据和领域模型发生根本性改变,那么在没有开发者人工介入的情况下,客户端将无法自动适配这些变动。


3) 超媒体毁掉了资源定位

  • REST阻止了来自客户端的固定URI和任何关于服务器资源的先验知识。在实践中,保存了URI(例如书签)和服务器的客户端,需要处理其URI空间的演变(重定向)。

  • 超媒体无法将API提供者与API使用者的惰性行为隔离开,后者将不会遵循恰当的超媒体流,而是直接针对目标资源和URI。

  • 由于超媒体API往往非常复杂,难以理解和使用,所以开发者将必然会优化其客户端并采用捷径——而这将会使为了将API变更与客户端隔离的所有努力化作泡影。


4) 对人类用户来说,超媒体富有意义;但对机器则并非如此

  • 机器并不善于处理随时间推移发生的变化,相反人类则非常擅长解读变更并决定下一步想要做什么。超媒体与人类在本质上非常贴近,而对机器来说这意味着相当程度的隔阂。

  • 领域模型方面的变动,要求客户端使用它的方式也发生改变,超媒体并没有对此采用什么特别的手法。

一个真正的REST/超媒体客户端,其实是人机交互(HCI)的一种形式,而不是API。(或者说,是AHI——应用与人交互)。


5) 带外数据究竟有什么坏处?

  • API是否真的有必要天生可发现?

  • 当API响应的格式具有高度复杂性、难以阅读的时候,API凭什么应该具有自我说明性(self documenting)?

  • 真正易于阅读的材料应该是:组织结构精妙的HTML、由浏览器渲染、具有交互式例子和清晰的描述。


6) 超媒体API与WADL真的不一样吗?

可发现的超媒体API有什么不同?“HAPI”看上去就像是一套WADL弥漫其中的API。我们依旧必须从单独一个端点开始,依旧必须了解基于其响应,我们可以用API干什么。

  • 其中部分必须具有领域模型的描述,而它们还将随时间推移发生改变。


7) Web的模拟

  • 假定这样一个场景:在原生移动应用中使用REST API,我们拥有两门语言(Android ML和iOSMLS,分别拥有所需的代码);

  • 使用针对特定领域的超媒体媒体类型,依旧需要编写能够理解这一领域的客户端代码。


8) 关于REST,有哪些是真正的优点?

  • 除了超媒体和文档网(Web of documents)外,REST还提供:

    • 强制要求无状态服务器,从而使其易于扩展

    • 鼓励通过资源将信息解耦合

      基础内容非常简单,我们可以与服务器以语义上富有意义的方式进行对话,而且只需要在所有平台和语言中包含http库即可。


以上摘要包含了对若干讨论参与者回复内容的摘抄,特别是Evan Cordell,以及Mike Amundsen、Jorn Wildt和Mike Kelly。作为免责声明,需要指出的是,本文作者也在开始阶段参与了这场讨论。


从自身的经验来看,各位读者是否认为我们需要更好地区分REST和Web API架构风格,区分人类驱动超媒体和M2M通讯的使用案例?


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 Appium 入门到原理合集 移动端尺寸基础知识 否极泰来,会是2016年中国制造业的写照吗? MVVM没你想象的那么的好