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 (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的优点
REST简单而直观，把HTTP协议利用到了极限，在这种**指导下，它甚至用HTTP请求的头信息来指明资源的表示形式（如果一个资源有多种形式的话，例如人类友善的页面还是机器可读的数据？），用HTTP的错误机制来返回访问资源的错误。由此带来的直接好处是构建的成本减少了，例如用URI定位每一个资源可以利用通用成熟的技术，而不用再在服务器端开发一套资源访问机制。又如只需简单配置服务器就能规定资源的访问权限，例如通过禁止非GET访问把资源设成只读。
服务器无状态带来了更多额外好处，因为每次请求都包含响应需要的所有信息，所有状态信息都存储在客户端，服务器的内存从庞大的状态信息中解放出来。而且现在即使一台服务器突然死机对客户的影响也微乎其微，因为另一台服务器可以马上代替它的位置，而不需要考虑恢复状态信息。更多的缓存也变成可能，而之前由于服务器有状态，对同一个URI的请求可能导致完全不同的响应。
总体结果是，网络的容错性和延展性都增强了，这些本来是WEB设计的初衷，日趋复杂和定制的WEB把它们破坏了，现在REST又返璞归真，试图把Web Service带回简单的原则中来。