萧百龄：喋喋不休困扰REST的两大问题

　　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 大力支持背后的主要动机（之一）。