喋喋不休困扰 REST 的两大问题

　　事实上，将 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 大力支持背后的主要动机(之一)。