BT

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

Roy Fielding:REST API必须是超文本驱动的!

| 作者 胡键 关注 0 他的粉丝 发布于 2008年12月31日. 估计阅读时间: 6 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

Fielding博士的那篇经典论文中文版)对万维网架构的贡献可谓是居功至伟。可想而知,当REST一词变得流行起来之后,其滥用甚至是“挂羊头卖狗肉”的现象是不可避免的。而糟糕的是,对于那些没有时间、也没有耐心去仔细阅读该论文的人来说,可能就会在看过或用过某些号称具有REST风格的应用之后对REST本身产生错误的理解,进而在错误的思想指导之下错误地运用REST。这正是其创造者本身所不愿意看到的。

这不,Fielding博士本人终于按捺不住发飚了。在其10月28日发表的博文《REST API必须是超文本驱动的》中,博士坦言了他的失望,并对SocialSite REST API提出了批评。同时他还指出,除非应用状态引擎是超文本驱动的,否则它就不是RESTful或REST API。据此,他给出了REST API应该具备的条件:

  • REST API不应该依赖于任何通信协议,尽管要成功映射到某个协议可能会依赖于元数据的可用性、所选的方法等。
  • REST API不应该包含对通信协议的任何改动,除非是补充或确定标准协议中未规定的部分。
  • REST API应该将大部分的描述工作放在定义用于表示资源和驱动应用状态的媒体类型上,或定义现有标准媒体类型的扩展关系名和(或)支持超文本的标记。
  • REST API绝不应该定义一个固定的资源名或层次结构(客户端和服务器之间的明显耦合)。
  • REST API永远也不应该有那些会影响客户端的“类型化”资源。
  • REST API不应该要求有先验知识(prior knowledge),除了初始URI(书签)和适合目标用户的一组标准化的媒体类型(即,它能被任何潜在使用该API的客户端理解)。

按照Fielding博士这些条件,一大批我们熟知的、号称是RESTful的应用和架构无疑都不属于REST的行列,包括Google/Amazon/Yahoo!等大公司所提供的API和应用。可想而知,该文发表之后的反响是巨大的,其后长长的回复列表即是明证。面对诸多疑问,Fielding博士一一做了回复。其言论整理如下:

  • 对于“超文本”,Fielding说道:“我所说的超文本指的是信息与控件的同时呈现,这样一来,信息便具有自解释性(affordance),从而用户(或程序)可以通过它获取选项、并作出选择。”(回复#3)
  • 他认为“真正的RESTful API”就想超文本一样,信息的每个寻址单元显式地(如,link和id属性)或隐式地(如,由媒体类型定义和表示结构推导而来)携带一个地址。(回复#5)鉴于超文本中已经包含了寻址信息,故而他认为接口并不一定需要是可发现的。(回复#11)
  • 对“为什么会有如此多的人对REST理解有误”之一问题,Fielding承认由于他时间的关系对媒体类型的设计未在论文中做详细阐述,但同时强调这并非表示他认为这些内容不重要。(#8)
  • 对于资源建模的目的,Fielding表示这是为了找出哪些资源值得标识、表示和操作。(回复#11)
  • 对于先验知识,Fielding认为客户端是允许有先验知识的,但REST强调的是这些先验知识应该以一种标准化的形式出现。(回复#20)
  • 对于批操作,Fielding认为人们觉得需要批操作是因为他们没有理解资源的范围。他指出资源并非存储项(至少不等同于后台中某些存储项),并且同一资源状态可以由多个资源来分担。如果谁发现他需要一个批操作,那么很可能只是因为他没有定义足够的资源。(回复#21)
  • 不要混淆了应用状态和资源状态,前者指的是计算某个任务的用户应用的状态,后者则是指作为某个服务所暴露出的状态(回复#22)
  • 媒体类型标识出了定义如何处理表示的规范。一旦表示以携带了类型化关系的超文本形式被提供,那么自动化的代理就能像人一样在这些应用之间穿梭自如。(回复#30)
  • 对于安全性的问题,Fielding说道:“RESTful系统实现安全操作的方式和其他任何消息传递协议的方式是一样的:不是封装消息流(SSL、TLS、SSH、IPspec……),就是加密消息(PGP、S/MIME等)。”(回复#34)

在这样短的一篇新闻中很难详细的罗列该文所有的内容和评论,尤其是其间不乏某些很有价值的讨论和观点。请一定要阅读一下Fielding博士的这篇引起广泛讨论的文章。另外,REST论文中文版的译者之一dlee也在JavaEye论坛上就此文发起了讨论。其中他这样写道:

Fielding发表这篇blog,这件事情其实并不出我的意外。我在两年前就很奇怪世界上为何一下子冒出来这么多REST专家。那一年,我翻译了《Ajax Patterns and Best Practices》。这本书的内容非常深入,作者Christian Gross宣称他所设计的所有模式遵循的都是REST架构风格。但是Gross先生却没有将REST的来龙去脉讲清楚,甚至只字未提Fielding的那本著名的博士论文。

REST似乎是一个技术界的罗生门,每个人的描述都不一样,而他们都坚信自己的理解才是正确的。……

现在真相大白了,Fielding对于REST架构风格定下了如此严格的判断标准,世界一下子清静了。

附注:非常感谢《RESTful Web Service中文版》的译者徐涵对本文提出的意见和帮助。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

agent会很累 by Guo Xiaogang

严格遵守那些定义的话,agent/client如何表达资源岂不是很受限制。


不能做到RESTful,RESTish也勉勉强强了。

颠覆 by Chen Zhengyun

本来先看的这篇文章:
www.ibm.com/developerworks/webservices/library/...

完全是一次颠覆。

Fielding想多了 by Zeng Abrams

Fielding是科学家,实现标准的是商人,当然不一样

允许的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通知我

3 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT