InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

争论:REST需要描述语言吗?

作者 Arnon Rotem-Gal-Oz 译者 胡键 发布于 2007年6月12日

领域
架构 & 设计,
企业架构
主题
Web服务 ,
REST ,
SOA
标签
契约优先开发 ,
WADL ,
WSDL

追踪上周在此讨论的关于REST vs. WS-*的争论,值得注意的是,以REST化服务契约为主题的争论在最近几天日嚣尘上。浮现出的问题是REST是否需要契约(即按照WSDL的方式),更更根本的问题是有了契约的REST还依旧是REST吗。Aristotle Pagaltzis的问题:“REST需要服务描述语言吗?” 揭开了争论的序幕:

“日前,有人在rest-discuss发问是否有描述REST服务的标准方法。该问题一再露面(作为回应,通常会画一个指向WADL努力的箭头),似乎意味着关于REST的一个流行的误解。我认为使用类WSDL语言描述REST化服务根本就是自相矛盾的说法……”

对此,Paul Mueller 回应道

“此处,我们讨论的是契约。契约必须以某种方式正规化。英语并非最好的使用语言,尤其是因为我们有如此多的更精确语言可供选择。

我的这个想法这实际上是对我关于数据序列化想法的扩展,服务只是需要被元描述的下一级事物。”

Mark Baker紧跟而上,他同意Aristotle的观点:REST拥有(以及需要)的唯一契约就是以4个动词为基础的HTTP协议,这4个动词是——POST、GET、DELETE、PUT(事实上HTTP 1.1还定义了另一个动词 - HEAD,但是它使用并不广泛)。Mike Herrick 认为契约确实能增加价值:

“我认为,REST客户端开发者至少期望能有模式,用来定义在请求/响应有效负荷中想出现的东西。恕我直言,WADL做了非常不错的工作,而且没有画蛇添足。如我所说,与WSDL相比较,它是个不错的东西。当HTTP是唯一选择的时候,事情是如此的简单(即,相比于愚蠢的协议不可知论调)。如果你不打算使用WADL,那你就不得不将服务以枯燥无聊的方式文档化。至少,WADL看起来是一种真正简化文档事物的方法。”

Bobby Woolf(因企业集成模式而闻名)同样认为REST需要声明性接口并怀疑当REST最终获得这些能力时,结果是否还会与WSDL有什么显著不同。John Heintz建议在其间做些手脚,使用他称之为路标的东西,而非描述语言。他的想法是:路标在运行时可以被解析,这将使它们适于改变。问题的症结似乎是:服务消费者对于接口的信心,它由它们所消费的服务定义。这个视角始于Stefan Tilkov的评论,他认为存根(stub)和骨架类(skelton)有问题。Don Box回复说你必需对你得到的消息结构有信心。对此,Stefan的回应:

“我同意这一点——我的代码就依赖文档中一些元素和属性。但问题是,即使我的应用只访问它所需要的XML中20%的元素和属性,列集(散列)/序列化(反序列化)((un)marshaling/(de)serialization)代码同样要求在XML和模式之间进行完美地匹配。目前代码产生时就是如此。换句话说:尽管我的应用代码能容忍至少一些变动,但是产生的底层代码则不行。”

Mike Glendinning的评论强调了Stefan的观点,他认为当用户只使用返回消息的20%时,为其本身定义新契约更有效。或者如Joe Gregorio写下的(在一个相当长的Q&A风格帖子中,它通篇都是关于我们是否需要WADL):

“Q:人们打算想要描述接口,那有什么坏处?

A:是的,人们想要描述接口,并且那些描述是脆弱的。如果今天我下载一个WADL并编译我的客户端,那么明天就会因你改变服务而崩溃。相反,如果你使用超文本(在链接后跟超文本和客户端状态,或基于超文本和客户端状态构造请求),那么当你改变服务器或URI结构时,接口将不会被破坏。”

最后,考虑到上文Stefan博客中的2条评论,问题可能比“REST是否需要正式的契约”更根本,即“我们需要接口吗?”。首先看看Steve Jones的评论:

“契约是个好东西,这已经是被证明的了,我仍然奇怪为什么REST人们不喜欢它们。它几乎是理论和实践的东西,在理论上并没有规定,在实践上却是如此。”

与Eric Johnson所说相比较:

“……就我看来,被REST所吸引(不论以什么形式)的人们,是反抗基于接口的编程而甚于WS-*本身——至少我的理由是如此……”
查看英文原文:Debate: Does REST Need a Description Language?。
译者简介:胡键,自2000年西安交通大学硕士毕业后一直从事软件开发。2002年开始使用Java,在项目开发中经常采用OpenSource工具,如Ant、Maven、Hibernate、Struts等,目前正在研究信息集成方面的规范和技术。可以通过jianhgreat@hotmail.com与他联系,或访问博客:http://foxgem.javaeye.com/。参与InfoQ中文站内容建设,请邮件至china-editorial@infoq.com

译者 胡键 热心开源技术,《开源技术选型手册》作者,《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。