喋喋不休困扰 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 大力支持背后的主要动机(之一)。