ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 喋喋不休困扰 REST 的两大问题( 2008年03月14日)

喋喋不休困扰 REST 的两大问题( 2008年03月14日)

原创 Linux操作系统 作者:tigerhsiao 时间:2009-04-29 14:14:05 0 删除 编辑
REST 是好东西,但受到两个问题的拖累。

  之前已经写过一些对 REST 的简介和看法。不久前恰好又在中文版的 infoQ 网站上看到一篇刚翻译成中文的文章,发现一些问题,于是又把整个 REST vs. SOAP 的论战再仔细看过一遍,刀光剑影,娱乐性十足。好消息是,最近这几个月,比较耸动或炒作性的 REST 话题似乎开始从网站、杂志头版消失。就来回顾和总结一下,事情其实很简单,REST 是被两个问题给害了。

  一是对 REST 技术本质的混淆,许多实现方式,号称是 REST,但其实不够格。这个比较容易解决。举例而言,infoQ 中文站今年一月刚发布一篇翻译自这篇 2006 年 5 月的文章(不推荐)。但不幸的是,作者选择将 POX (Plain Old XML) over HTTP 的实现方式,冠上 REST 和 RESTful 的封号。但看看作者天气查询的例子,最讽刺的是,如果看它采用的 XML 输入、输出格式,和用 HTTP POST 的交互方式,活像是个 SOAP-based 的 Web services - 只差没用 SOAP 信封格式将输入、输出文件包装起来。至于该 Web services 采用诸如 http://x.com/weather/WeatherQuery/2.0

  这种统一 end-point URI 网址的设计,更是犯了 REST 的大忌。真正合格的 REST 设计,就拿相同的天气查询做例子,服务调用(消费)端应该可以直接 GET 一个像

  http://x.com/weather/city/chicago

  或

  http://x.com/weather/zip/60661

  这样的独特网址,无需另外将参数透过输入文件,就能够获取查询结果。

  我们真正需要的,是更多像 Stefan Tilkov 这篇正视听的 REST 教学(中文版:深入浅出REST)。另外,我发现 Wikipedia 中对 REST 和 RPC 所作的比较,也非常有帮助,能够让习惯 OO 的开发人员快速体认到 REST 的设计哲学。在另一篇 infoQ 的文章中(同样推荐,但没看到有中译),作者探讨 REST 的 URI 超链接设计原则,并指出连 Flickr 等大站的 REST API,都看得到关于这个原则的错误示范。

  大量似是而非、自封为 REST/RESTful 范例的充斥,混淆了视听;令人担心的是,它们会引发“POX+HTTP 是 REST,因此 POX+HTTP 自然具备了 REST 优势” 的错误推论。

  来看过去一年 REST 热潮的第二大问题。这个问题比较棘手。根源在于某些激进派选择以 REST 单挑 SOAP+WS-*,且带着汉贼不两立的互斥、排他心态,来宣扬 REST 理念,彼得雷西 (Pete Lacey) 是其中的急先锋。正因为对上了 SOAP,企业计算和 SOA 的课题也不免被扯了进来。在 consumer Web 2.0 领域中,用户量巨大,信息相对公开,往往不需要如企业领域做到很细微的安全控制,REST 式的 Web services,过去几年在效能方面发挥得很出色;此外,简单易用,让想开发 mashup 等复合式应用的广大开发人员,能快速上手。这些都是有目共睹的。但 REST 的成功,逻辑上无法直接引申成 SOAP 的失败。此外,REST 狂热者往往以 HTTP 正统自居,认为不遵循 REST 原则和风格,便是对 HTTP 的“滥用”,例如在《深入浅出REST》一文最后,作者就表达了这样的态度。一位网友 Alex Xu 评得好:

  为什么要把REST跟SOAP对立起来?

  JSP,ASP,PHP难道不也是对HTTP的“滥用”吗?(按照REST的原则)

  电话线原本是给电话用的,但是后来人们用它来发传真,又用调制解调器上网,再后来ADSL,现在ADSL+.在这种途径上人们不断地挖掘潜力.为什么HTTP就不行呢?

  但正因为抱持了基本对立的立场,彼得雷西在这篇专访中,几近全盘否定地,一一数落 SOAP、WSDL、UDDI、WS-*,甚至 XSD 的不是。过分膨胀的论点,自然也招来了许多反证。例如 Paul Fremantle 表示据他所知,eBay 的 SOAP 服务每天要处理四千万的请求,而 Yahoo Mail 基本上也是基于 SOAP,而请求量也不会小。其他像是 SOA 专家 Steve Jones 驳斥了雷西关于解析 XSD 和 XML 文件格式弹性方面的抱怨。

  事实上,将 REST 和 SOAP+WS-* 看作有非此即彼的替代性,不如把它们看作是互补,让负责实现 Web service 的开发人员自行选择实现的方式。SOA 的原则本来自当如此 -- 由业务分析师和 IT 架构师先识别出服务,以契约(合同)的方式加以规范,而服务契约应该是独立于任何技术平台或实现手段之上的。接着下来才是讨论绑定方式、服务接口设计,和实现手段。同样的一套业务逻辑代码,可以根据为满足契约的实际情况,以多种方式封装、绑定。契约、接口、代码实现,乃至于团队分工方式,都应该是松耦合的。

  正如 Steve Jones 在多篇批判 REST 的博客中指出,更重要的是 IT 要如何更紧密地配合业务的变化,更快地去实现业务能力,这是 SOA 自始至终的目标。至于如何将一个文件从甲地运送到乙地,方式很多,REST 只不过是 SOAP、REST、JMS、RMI、MQ... 等众多选择之一而已,不该本末倒置。

  SOAP、WSDL 和几个主要的 WS-* 标准,多年发展下来,厂商和工具支持已相对成熟。REST 虽然在先天结构上较为简单,但就像彼得雷西自己在这篇博客回应中举的例子,选择 REST 的开发人员必须评估,在工具、框架支持相对不成熟的情况下,coding 的代价高不高?另外我想到一个普遍的企业应用场景 -- 当有安全私密性要求时,REST 应用可以很轻易地搭配 SSL/TLS。但内容一旦加密,许多被 REST 支持者津津乐道,包括能直接利用 Web 现有缓存机制的高伸缩性,便不复存在。有时候,甚至在内容没有必要加密时,因为必须根据用户身份权限对内容做过滤、个性化,此时如果采用 REST 和 HTTP GET,还必须确定告诉客户端和服务器之间所有行经的 Web 基础设施不许缓存,以免内容让不该看的人看到(不同于过去清一色 HTTP POST 的请求回应,默认的行为本来就不会缓存,许多开发人员早已视为理所当然)。在这类情况下,其他剩下来的 REST 优势(如简易),是否仍超越采用其他的技术手段?是企业开发人员必须面对的。

  有的科技大厂眼见 consumer Web 2.0 地盘长期以来被 LAMP 和 PHP、Ruby、JavaScript、Python 等占据,除了实验性地扶植 Groovy、Grails 之类外,现在冒出了这群 REST 激进派信徒,制造出非常戏剧性的冲突,大火既已点燃,岂可不好好利用一下 - 管他是否过分炒作或自我膨胀,先趁势而上,运用市场机器,加入炒作行列;同时推出一些支持 REST 的理论架构、开发框架、规范、或工具,借机让 Java 和 C# 的影响力能扩大到 Web 2.0 领域(包括消费和企业 Web 2.0)。我感觉这是厂商宣布对 REST 大力支持背后的主要动机(之一)。

  图片来源:bblfish.net/blog/page1.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16186206/viewspace-592243/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-09-26

  • 博文量
    20
  • 访问量
    51593