REST 的最大价值，在于它的简约；只要遵循上回帖子中提到的几个基本原则，便可直接充分利用 HTTP 和 Web 服务器先天具备的架构优势，包括 GET 的请求会被 Web 服务器有效地缓存，和因不需要维系各别的会话状态，而达到非常高的伸缩性。Google 和 Amazon 等所提供的 Web services，是最好的明证。这是 REST 的拥护者津津乐道的论点。
但如果照目前的气氛继续发展下去，过分炒作“REST 是比 SOAP 更适合于 SOA 的技术实现手段”、“SOA 未来的希望在 REST”这类危险的观念（上回谈的主题），其最终的结果，可能是既伤害了 REST，又对 SOA 没好处的双输局面。
此话怎讲？
目前一般认定的（企业级） SOA 服务，必须具备让有兴趣想调用该服务的消费者，自动发掘确切的服务端点、接口、和 XML 的 schema 结构的能力。在经常被引述、由Thomas Erl 所列的 SOA 八大原则中，便包括了 Discoverability 这条。此外，InfoQ 的 SOA 十大原?中的第三和第七个原则，也都与此相关（附带一提，关于这个“十大原则”，我认为它愈到后面，愈有画蛇添足的感觉，尤其是最后三条）。
不同于 SOAP，RESTful 形式的 Web services 是没有信封机制，只有赤裸裸的 payload，而 payload 的内容，往往是 POX (Plain-Old XML)，当然也有人使用 JavaScript 对象表述 JSON。仅单就 XML而言，如果光是一个 instance，是无法确定其确切的 schema 结构到底是什么样子的。RESTful 的 Web services 先天上既缺乏像 SOAP 那样的一套信封 header 机制，可以用来注明相关的元数据，如 XML schema，又不像 SOAP 还有一个WSDL 搭档，来描述各种和服务相关的元数据，因此无法满足上述的 discoverability 原则（有些嘴硬的 REST 拥护者说可以通过 MIME type 来表述服务的元数据，但此说实在过于牵强）。当然，只要服务供应者通过网站发布清楚的服务 API 描述，通过事先的设置，RESTful 的 Web services 同样可以圆满达成任务，这样的例子在Web 2.0 的世界太多了，只是说，这样的服务，缺乏一套让消费者自动探索的机制，藉此利用自动化的工具，方便服务的组装和开发。
不意外地，随着 REST 的发烧，愈来愈多人探讨 REST 是否也像 SOAP 一样，需要描述语的问题（例如这里和这里）。WADL 正是为满足 discoverability 需求下的产物。Sun 更已经把它纳入新的 JAX-RS 的一部分（关于 WADL，这儿有篇不错的简介）。有人批评 JAX-RS，指出它是想像 JAX-WS 之于 SOAP 那样，把根源于 CORBA IDL 和 Java interface那套面向对象的编程机制和架构，硬套到 REST 上。但如上次帖子里谈到的，REST 的应用设计理念和这样的作法，将格格不入。换句话说，它将不当地鼓励开发人员把 REST 当作“只不过是另一种 SOAP”来看待，而完全忽视 REST 的设计理念。REST 原始的精神和价值，将因而荡然无存。
除了 WADL 之外，如果 RESTful服务需要注明各种需要强制的服务战略 (policy)，像服务水平、安全（身分认证、加密、签名...），另外像可靠性、交易等属性，是不是也需要有一个像 header 的地方，来放这些属性？按照这个趋势继续发展下去，有什么可以阻挡支持 REST 的大厂们，把它变成另一个 SOAP的？
还记得 SOAP 的诞生，最早可追溯到 Dave Winer 和 Don Box 等最早发展 XML-RPC 的那段历史吗（可参考 Wikipedia 的记载）？自从 SOAP 的发展从 RPC 导向转成文件导向，复杂度升高后，XML-RPC 的创始人 Dave Winer 因种种因素，遂转而去发展 RSS。我还记得约九年、十年前，RSS 还在 1.0 版本时，一般认定 RSS 的全名为 "Rich Site Summary" 或 "RDF Site Summary"。但自 Winer 氏积极参与 RSS 2.0 的制定后，开始将 "RSS" 用来代表 "Really Simple Syndication"。从他对 "RSS" 三个字母所代表的意涵诠释上，便明确显示出其对“简约”的强调。
随着将 REST 用于企业级 SOA 应用的声浪，REST 看来将承受愈来愈重的包袱，WADL 规范的推出，只不过是冰山的一角。我们必须好好问问，让 REST 重演当初从 XML-RPC 一路到 SOAP 1.2 的复杂化历史，是否具备充分的正面意义？
发表于 @ 2007年08月28日 14:11:00|评论(loading...)|编辑