REST的最大价值，在于它的简约；只要遵循基本原则，便可直接充分利用HTTP和Web服务器先天具备的架构优势，包括GET的请求会被Web服务器有效地缓存，和因不需要维系各别的会话状态，而达到非常高的伸缩性。Google和Amazon等所提供的Webservices，是最好的明证。这是REST的拥护者津津乐道的论点。

　　但如果照目前的气氛继续发展下去，过分炒作“REST是比SOAP更适合于SOA的技术实现手段”、“SOA未来的希望在REST”这类危险的观念，其最终的结果，可能是既伤害了REST，又对SOA没好处的双输局面。

    此话怎讲？

　　目前一般认定的（企业级）SOA服务，必须具备让有兴趣想调用该服务的消费者，自动发掘确切的服务端点、接口、和XML的schema结构的能力。在经常被引述、由ThomasErl所列的SOA八大原则中，便包括了Discoverability这条。此外，InfoQ的SOA十大原则中的第三和第七个原则，也都与此相关（附带一提，关于这个“十大原则”，我认为它愈到后面，愈有画蛇添足的感觉，尤其是最后三条）。

　　不同于SOAP，RESTful形式的Webservices是没有信封机制，只有赤裸裸的payload，而payload的内容，往往是POX(Plain-OldXML)，当然也有人使用JavaScript对象表述JSON。仅单就XML而言，如果光是一个instance，是无法确定其确切的schema结构到底是什么样子的。RESTful的Webservices先天上既缺乏像SOAP那样的一套信封header机制，可以用来注明相关的元数据，如XMLschema，又不像SOAP还有一个WSDL搭档，来描述各种和服务相关的元数据，因此无法满足上述的discoverability原则（有些嘴硬的REST拥护者说可以通过MIMEtype来表述服务的元数据，但此说实在过于牵强）。当然，只要服务供应者通过网站发布清楚的服务API描述，通过事先的设置，RESTful的Webservices同样可以圆满达成任务，这样的例子在Web2.0的世界太多了，只是说，这样的服务，缺乏一套让消费者自动探索的机制，藉此利用自动化的工具，方便服务的组装和开发。

　　不意外地，随着REST的发烧，愈来愈多人探讨REST是否也像SOAP一样，需要描述语的问题（例如这里和这里）。WADL正是为满足discoverability需求下的产物。Sun更已经把它纳入新的JAX-RS的一部分（关于WADL，这儿有篇不错的简介）。有人批评JAX-RS，指出它是想像JAX-WS之于SOAP那样，把根源于CORBAIDL和Javainterface那套面向对象的编程机制和架构，硬套到REST上。但如上次帖子里谈到的，REST的应用设计理念和这样的作法，将格格不入。换句话说，它将不当地鼓励开发人员把REST当作“只不过是另一种SOAP”来看待，而完全忽视REST的设计理念。REST原始的精神和价值，将因而荡然无存。

　　除了WADL之外，如果RESTful服务需要注明各种需要强制的服务战略（policy），像服务水平、安全（身分认证、加密、签名……），另外像可靠性、交易等属性，是不是也需要有一个像header的地方，来放这些属性？按照这个趋势继续发展下去，有什么可以阻挡支持REST的大厂们，把它变成另一个SOAP的？

　　还记得SOAP的诞生，最早可追溯到DaveWiner和DonBox等最早发展XML-RPC的那段历史吗（可参考Wikipedia的记载）？自从SOAP的发展从RPC导向转成文件导向，复杂度升高后，XML-RPC的创始人DaveWiner因种种因素，遂转而去发展RSS。我还记得约九年、十年前，RSS还在1.0版本时，一般认定RSS的全名为“RichSiteSummary”或“RDFSiteSummary”。但自Winer氏积极参与RSS2.0的制定后，开始将“RSS”用来代表“ReallySimpleSyndication”。从他对”RSS”三个字母所代表的意涵诠释上，便明确显示出其对“简约”的强调。

　　随着将REST用于企业级SOA应用的声浪，REST看来将承受愈来愈重的包袱，WADL规范的推出，只不过是冰山的一角。我们必须好好问问，让REST重演当初从XML-RPC一路到SOAP1.2的复杂化历史，是否具备充分的正面意义？