首先什么是SOAP？

SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，

用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。

事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，

以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，

又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。

另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，

定义的API也不尽相同，这又导致了WSDL的诞生。

什么是WSDL？

WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，

怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，

获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，

然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。

绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

在来看看什么是REST？

REST (REpresentational State Transfort) 形式上应该表述为客户端通过申请资源来实现状态的转换，

在这个角度系统可以看成一台虚拟的状态机。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的优点？

REST简单而直观，把HTTP协议利用到了极限，在这种思想指导下，

它甚至用HTTP请求的头信息来指明资源的表示形式（如果一个资源有多种形式的话，

例如人类友善的页面还是机器可读的数据？），用HTTP的错误机制来返回访问资源的错误。

由此带来的直接好处是构建的成本减少了，例如用URI定位每一个资源可以利用通用成熟的技术，

而不用再在服务器端开发一套资源访问机制。又如只需简单配置服务器就能规定资源的访问权限，

例如通过禁止非GET访问把资源设成只读。

服务器无状态带来了更多额外好处，因为每次请求都包含响应需要的所有信息，

所有状态信息都存储在客户端，服务器的内存从庞大的状态信息中解放出来。

而且现在即使一台服务器突然死机对客户的影响也微乎其微，因为另一台服务器可以马上代替它的位置，

而不需要考虑恢复状态信息。更多的缓存也变成可能，而之前由于服务器有状态，

对同一个URI的请求可能导致完全不同的响应。

总体结果是，网络的容错性和延展性都增强了，这些本来是WEB设计的初衷，

日趋复杂和定制的WEB把它们破坏了，现在REST又返璞归真，试图把Web Service带回简单的原则中来。