什么是SOAP?

SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的api，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

什么是REST？

REST (REpresentational State Transfort) 形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。抛开R. T. Fielding博士论文里晦涩的理论不说，REST应该满足这样的特点：1)客户端和服务器结构；2)连接协议具有无状态性；3)能够利用Cache机制增进性能；4)层次化的系统；5)按需代码。说到底，REST只是一种架构风格，而不是协议或标准。但这种新的风格（也许已经历史悠久？）对现有的以SOAP为代表的Web Service造成的冲击也是革命性的，因为它面向资源，甚至连服务也抽象成资源，因为它和HTTP紧密结合，因为它服务器无状态。

REST与SOAP的区别

因为SOAP并不假定传输数据的下层协议，因此必须设计为能在各种协议上运行。即使绝大多数SOAP是运行在HTTP上，使用URI标识服务，SOAP也仅仅使用POST方法发送请求，用一个唯一的URI标识服务的入口。举一个图书馆在线查询管理系统为例，服务提供者必须为每一本书提供一个内部标识，然后可能定义一个listBooks操作来返回一系列图书，一个getBook操作来返回指定的图书，一个createBook操作来向数据库加入新增的图书，一个deleteBook操作来删除作废的图书，每个操作都有各自的参数，尤其是用内部标识来标识操作的图书。这种设计被诟病之处，在于deleteBook操作也要用POST方法来发送，而其实HTTP协议有更和逻辑的DELETE方法可用。REST正是这样设计的，REST为每一个资源（此处是图书）指定一个唯一的URI，而用HTTP的4种方法GET、POST、PUT、DELETE直观地表示获取、创建、更新和删除图书。同时图书集合也是和单本的图书不同的资源，如果用/books来代表图书列表，/books/ID来代表标识为ID的图书，那么对/books的GET操作就代表返回整个图书列表，对/books/ID的DELETE操作代表删除指定的图书，等等。

REST API
    优点：
        1. 轻量级的解决方案，不必向SOAP那样要构建一个标准的SOAP XML。
        2. 可读性比较好:可以把URL的名字取得有实际意义。
        3. 不需要SDK支持：直接一个Http请求就可以，但是SOAP则可能需要使用到一些Webservice的类库（例如Apache的Axis）
    缺点：
        1. 复杂的应用中，URL可能非常长，而且不容易解析。
SOAP API
    优点：
        1. 定义严格。必须符合SOAP的格式
        2. 某些时候使用比较方便
        3. 开发工具支持比较多一点。
    缺点：
        1. 需要生成WSDL文件

REST是万能的吗？

但是REST就是万能的吗？无状态带来了巨大的优势，同时也带来了难以解决的问题，例如，怎样授权特定用户才能使用的服务？怎样验证用户身份？如果坚持服务器无状态，也就是不记录用户登录状态，势必要求每一次服务请求都包含完整的用户身份和验证信息。在这种情况下，怎样避免冒认？怎样避免用户信息泄漏？事实上，构建REST附属的安全机制已经在讨论中，其结果无非导致另一个SOAP：复杂的需求摧残了易用性。

REST的支持者声称REST的请求和应答数据简单可读，而SOAP则需要一系列繁琐的封装；即使如此，SOAP仍然不能达到接口的一致性，不同的厂商有各自的接口，而REST只使用HTTP定义的方法，因此是通用的。事实确实如此吗？试想用REST实现两数求和的服务，如果按照建议的做法，把服务（此处是加法）作为一个资源，参数（此处是两个加数）作为请求的参数，结果以XML或JSON语法返回，是否比SOAP更简单易用？通用接口仍然没法达到，因为资源的名称、参数的名称、结果的格式仍然是服务提供者定义的。为了解决这个问题，提出了WASL(Web Application Description Language)来描述REST接口。WADL就像是WSDL的REST版，随着REST被应用到复杂的领域，SOAP的影子无处不在。

面向资源和面向事务

REST在面向资源的应用中左右逢源，但在面向事务的应用中却未如人意。面向资源的应用操作简单，无非创建、读取、改变、删除几项，但是面向事务的应用不允许用户直接操作资源，用户只需向系统提交一个事务说明要求，然后等待事务的完成，就如一个网上银行的用户不直接修改账户和存款，而是提交一个事务告诉银行自己要转账。如果把这样的服务看成一种资源，通过向资源发送POST请求完成事务，那不过是SOAP的翻版而已，无论是这样，还是通过PUT来创建事务，都改变了系统的状态（资源本身未改变，此处是改变了用户的余额），显然违背了REST直观的初衷。

事实上，一些Web Service提供者提供的REST API只有REST的外壳，传输的请求和应答全然是简化了的SOAP，这种新瓶装旧酒的做法只是加深了标准的分歧而已。归根结底REST无法简单地解决一些应用，因此我们只能看到SOAP在REST外壳下的借尸还魂。没有一项技术能一劳永逸地解决所有问题，只需要在预定的约束下优美地解决所在领域的问题就足够了。一项新技术推出的时候总是引来无数的跟风和吹捧，只有当尘埃落定之后才能得到中肯的评价。