SOAP vs. REST是一个伪命题，对它们进行直接比较并不恰当，因为SOAP（简单对象访问协议）是一种协议，而REST（表述性状态转移）是一种架构风格。
协议和架构是两种完全不同层面的东西，协议是计算机网络中信息交换的规则、标准和约定，其偏向于技术细节和底层；架构则是在系统层面的基准规范、通用性和原则，其偏向于抽象和顶层。一种协议可以用在不同的架构中，在架构的建设过程中也可以使用多种协议。但我还是把它们两者拿出来进行比较，因为它们都可以用于构筑Web Service。Web Service的最大作用在于其互操作性，它独立于平台、语言，可以让不同的应用程序互相调用。
通俗地讲，Web Service扫除了远程对象或方法调用的障碍，它是疏通不同应用程序或服务器之间信息沟通的桥梁。
1.基本概念
在我之前的两篇文章SOAP介绍和REST介绍中，我已经较为详细地说明了SOAP和REST的一些概念和渊源。如果您对这两者的概念还不甚清楚，可以先阅读这2篇文章。
SOAP
SOAP可以看作是XML-PRC的升级版本，它是一种轻量的、简单的基于XML的协议，允许应用程序通过HTTP或其它传输协议来交换信息，SOAP是用于访问Web Service的协议。
REST
REST是一种价格风格，不是一个标准。REST定义了一组体系架构原则，它借助HTTP的标准方法（POST，GET，PUT，DELETE），实现了对资源的CRUD操作。
2.SOAP和REST的比较
一个SOAP客户端像一个桌面应用程序，它和服务端的是紧耦合的。
SOAP客户端和服务端之间维护一个共同的严格的契约。当客户端的调用模型变更时，服务端需要变更契约以适应客户端；当服务端的契约变更时，SOAP客户端也必须手动或自动更新其契约，否则客户端和服务端之间将无法通信。
一个REST客户端更像一个浏览器应用程序，它和服务端是松耦合的。
REST服务端为每个资源提供统一的操作方法，这些操作方法都基于HTTP的标准方法，并且共用一个URI。同样地，REST客户端通过HTTP标准方法和URI操作服务端的资源。
由于客户端的访问方式和REST服务端提供操作的方式高度一致，并且都遵循HTTP的标准，所以当服务端或者客户端的业务逻辑变更时，客户端和服务端的调用基本不需要变更。
下图分别列出了SOAP Web Service和RESTful Web Service的调用方式
从另外一个角度看，SOAP Web Service公开的是操作（Operation），每一个操作都具有不同的逻辑。
RESTful Web Service公开的是资源（Resource），每一个资源都可以支持CURD操作。
下面列出了SOAP Web Service和REST Web Service的几点不同：
- 通信协议：SOAP支持主流通信协议，除了支持HTTP协议外，它还支持HTTPS, TCP, UDP等协议，它是协议中立性的。REST仅支持HTTP协议和HTTPS协议。
- 数据格式：SOAP仅支持XML数据格式，因为SOAP消息格式是XML的。REST支持多种数据格式，它支持XML、JSON、HTML和txt等。
- 安全性：SOAP支持SSL和WS-security。REST仅支持点对点的SSL安全。
- 请求方法：SOAP的请求方法仅支持HTTP POST。REST的请求支持HTTP的标准方法，例如：GET/POST/PUT/DELETE。
- 数据缓存：基于SOAP的数据读取不能够缓存。基于REST的数据读取则可以缓存，REST比SOAP在数据读取方面有更好的性能和扩展性。
这里的缓存是指客户端的缓存，在服务端我们当然可以借助于Session来实现缓存的目的，但这会加重服务器的负担。 - 状态管理：由于SOAP支持不同的通信协议，基于HTTP或HTTPS构建的WS可以认为是无状态的；除此之外，我们可以任务是有状态的。而REST只能支持HTTP和HTTPS协议，所以其资源管理是无状态的。
- ACID事务：SOAP支持事务的ACID特性。REST虽然支持事务，但并不完全支持事务的ACID特性。
庆幸的是，ACID事务是数据库的事务，在Internet中，我们用到它的场景并不多