简介
SOAP
简单对象访问协议（英文：Simple Object Access Protocol ）定义了一种强类型的消息传递框架，该框架高度依赖XML和schemas。
REST
表述性状态传递（英文：Representational State Transfer）。
通俗的语言解释REST：一句话：URL定位资源，用HTTP动词。
区别
底层协议
- SOAP本身便是基于HTTP而发展的协议。
- REST与HTTP几乎一样，REST规范没有强制的要求。
数据格式
- SOAP只依靠XML来提供消息传递服务。在某些情况下，消息传递服务可能变得极其复杂。例如，通过javascript访问Web服务，
- REST可以语言自由的选择易解析的数据格式。例如，CSV、JSON、XML、YAML等等。
有状态
- SOAP Web服务是无状态的，但是可以通过修改服务器上的代码轻松变为有状态的。
- RESTful Web服务是完全无状态的。对话状态的管理完全由客户端进行控制。服务端不保留任何状态信息。也就是我们通常所说的，客户端的每次请求必须携带所有可能用到的信息。
HTTP的方法使用
- SOAP可以对HTTP协议进行绑定。当绑定HTTP协议时，所有的SOAP请求都通过HTTP POST发送。
- REST主要使用HTTP协议。通过HTTP GET、POST、PUT、DELETE和PATCH方法进行CRUD操作。
缓存
- SOAP可以使用HTTP传输机制，但是都转换为HTTP POST方法。而POST是非幂等的，所以无法在HTTP级别进行缓存。因此SOAP的响应需要通过Response Caching Optimization Module给的信息进行缓存。
- REST可以发送HTTP GET请求，GET是幂等的，因此REST可以使用HTTP提供的缓存机制，使响应数据可以标记为可缓存或不可缓存。
安全
- SOAP通过WS-SECURITY对安全进行了很好的标准化。
- REST主要使用HTTP协议，HTTP本身是非常不安全的，但通过TLS它可以支持基础的身份认证和通信加密，即HTTPS。此外，在服务器上还可以进一步实施安全措施。
异步处理
创建和更新通常非常消耗资源，有时会需要异步请求处理。
- SOAP 1.2提供了额外的标准，可保证应用的可靠性和安全性。例如：WSRM –WS-Reliable Messaging。
- REST我们通常返回HTTP状态码202（Accepted）和队列位置，该位置上，任务的完成状态将会被定期更新（当然，我们也可以将完成状态信息存在数据库中，并定期新增状态信息，供客户端查询）。
何时选用REST
- REST 使用了标准 HTTP 因此它做什么都更加简单。创建客户端，开发 API，文档更易于理解，而且没有一件事用 REST 做起来不比 SOAP 更简单/更好。
- REST 允许很多不同的数据格式而 SOAP 仅支持 XML。虽然这样看起来给 REST 增加了复杂度因为你需要处理多种格式，但以我的经验来看这样实际上有很多好处。JSON 通常更适用于承载数据而且解析起来更快。由于其对 JSON 的支持，REST 允许我们更好地支持浏览器客户端。
- REST 具备更好的性能和可扩展性。REST 读取可以被缓存起来，而基于 SOAP 的读取无法被缓存。
- 用来做论据不太好(权威)，但是值得一提的是 Yahoo 的包括 Flickr 和 del.ici.ous 在内的所有服务都使用了 REST。Amazon 和 Ebay 两种都有使用，尽管 Amazon 内部使用的几乎全都是 REST 资源。Google 曾经对于他们所有的服务仅提供 SOAP，但 2006 年起 Google 弃用了 SOAP 转投 REST 资源。有趣的是在 Amazon 内部是否也有过关于 REST Vs SOAP 的争议，但是最终还是 REST 主宰了他们 web services 的架构。
何时选用SOAP
web services 安全
SOAP 不仅像 REST 一样支持 SSL，而且还支持增加了很多企业级安全特性的 WS-Security(WS = web services)。因此它能够提供通过中介的身份验证，而不仅仅是端对端的验证(SSL)。此外，SOAP 还提供了一个数据完整性和数据隐私性的标准实现。叫它“企业级”并不是说它更安全，它只是简单提供了典型互联网服务不需要的几个安全工具而已，事实上这些工具只有在很少的一些“企业级”场景下才能派的上用场。
web services 原子性事务
如果服务需要 ACID 事务的话，那么你就需要 SOAP 了。尽管 REST 也支持事务，但它并非完整性的而且不具备 ACID。幸运的是 ACID 事务对于互联网来说几乎没有任何意义。REST 受限于 HTTP，HTTP 本身无法提供两阶段提交分布式事务资源，但是 SOAP 可以。互联网应用一般不会需要这等级别的事务可靠性，企业级应用有时会需要。
web services 消息可靠性
REST 不具备一个标准的消息体系，它期望客户端通过重试来处理通信失败。SOAP 具备内置的成功/重试逻辑并通过 SOAP 中介来提供端对端的可靠性。
总结
总之，SOAP 显然是有用的，而且还很重要。例如，如果我去写一个连接到我的银行的 iPhone 应用那么我当然需要使用 SOAP。上述三点特性都是银行事务所必须的。比如，如果我将资金从一个账户转移到另外一个账户，我需要确定它的完成。如果第一次转账成功，但响应失败，这个时候的 REST 重试将会是灾难性的。
