一、Soap和Rest的定义
SOAP（Simple Object Access Protocol 简单对象访问协议），用于在Web Service中把远程调用和返回封装成机器可读的格式化数据，事实上SOAP使用XML数据格式，以描述调用的远程过程、参数、返回值和出错信息等等。其实SOAP最早是针对RPC的一种解决方案，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高，而且随着需求的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。SOAP 常常被称作“web services”，这是一个误称。SOAP 和 web 基本上说不上话。REST 提供的才是真正的基于URL 和 HTTP 的 “web services”。
REST(Representational State Transfort表述性状态传递)形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。按照REST原则设计的软件、体系结构，通常被称为“REST式的”（RESTful），抛开R. T. Fielding博士论文里晦涩的理论不说，REST应该满足这样的特点：
1)客户端和服务器结构；
2)连接协议具有无状态性；
3)能够利用Cache机制增进性能；
4)层次化的系统；
5)按需代码。
REST只是一种架构风格，而不是协议或标准。但这种新的风格对现有的以SOAP为代表的Web Service造成的冲击也是革命性的，因为它面向资源，甚至连服务也抽象成资源，因为它和HTTP紧密结合，且服务器无状态。服务器端采用J2EE，客户端采用JSP、Flex、JavaFX、AIR等可以直接调用Servlet，其他的实现技术基本上不能直接调用，但是无论是那种客户端，对于基于SOAP的Web服务或者基于RESTful Web服务务都是支持的，如AJAX的 XMLHttpRequest、Flex的HTTPService等。
二、Soap VS Rest
①在成熟度上
soap对于异构环境服务发布与调用，以及厂商的支持都达到了一定的成熟度，不同平台，开发语言通过soap来交互web service都能较好的互通；
rest是一种基于http协议实现资源操作的思想，但是没有类似于soap的权威性协议作为规范，rest实现的各种协议只能算是遵循rest思想的私有协议，所以在细节方面没有太多的约束。
soap在成熟度上优于rest。
②效率和易用性
soap协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS_*系列就是较为成功的规范。但是soap由于各种需求不断扩充其本身协议的内容，导致soap在处理方面的性能有所下降，同时在易用性和学习方面的成本有所提升；
rest被人们所重视，很大一方面是因为其高效以及简洁易用的特性，这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了http最初的应用协议设计理念，同时，rest还有一个很吸引开发者的就是能够很好地融合当前web2.0的很多前端技术来提高效率，例如很多大型网站开放的rest风格的API都会有很多种返回形式，除了传统的XML作为承载，还有json、rss、atom等形式，这对很多前端开发人员来说就能够很好的mashup各种资源信息。
在效率和易用性上，rest更胜一筹。
③在应用设计和改造上
rest对于资源服务型接口来说很合适，同时特别适合对于效率要求很高，但是对于安全不高的场景，而soap的成熟性可以给安全要求性和高的接口设计带来便利，所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是要适合应用场景。
三、Why Rest？
- REST 使用了标准 HTTP 因此它做什么都更加简单。创建客户端，开发 API，文档更易于理解，而且没有一件事用 REST 做起来不比 SOAP 更简单/更好。
- REST 允许很多不同的数据格式而 SOAP 仅支持 XML。虽然这样看起来给 REST 增加了复杂度因为你需要处理多种格式，但以我的经验来看这样实际上有很多好处。JSON 通常更适用于承载数据而且解析起来更快。由于其对 JSON 的支持，REST 允许我们更好地支持浏览器客户端。
- REST 具备更好的性能和可扩展性。REST 读取可以被缓存起来，而基于 SOAP 的读取无法被缓存。
举一个图书馆在线查询管理系统为例，服务提供者必须为每一本书提供一个内部标识，然后可能定义一个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操作代表删除指定的图书，等等。
四、Why Soap？
①web services 安全
SOAP 不仅像 REST 一样支持 SSL，而且还支持增加了很多企业级安全特性的 WS-Security(WS = web services)。因此它能够提供通过中介的身份验证，而不仅仅是端对端的验证(SSL)。此外，SOAP 还提供了一个数据完整性和数据隐私性的标准实现。叫它“企业级”并不是说它更安全，它只是简单提供了典型互联网服务不需要的几个安全工具而已，事实上这些工具只有在很少的一些“企业级”场景下才能派的上用场。
②web services 原子性事务
如果服务需要 ACID 事务的话，那么你就需要 SOAP 了。尽管 REST 也支持事务，但它并非完整性的而且不具备 ACID。幸运的是 ACID 事务对于互联网来说几乎没有任何意义。REST 受限于 HTTP，HTTP 本身无法提供两阶段提交分布式事务资源，但是 SOAP 可以。互联网应用一般不会需要这等级别的事务可靠性，企业级应用有时会需要。（ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））
③web services 消息可靠性
REST 不具备一个标准的消息体系，它期望客户端通过重试来处理通信失败。SOAP 具备内置的成功/重试逻辑并通过 SOAP 中介来提供端对端的可靠性。
例如，如果我去写一个连接到我的银行的 iPhone 应用那么我当然需要使用 SOAP。上述三点特性都是银行事务所必须的。比如，如果我将资金从一个账户转移到另外一个账户，我需要确定它的完成。如果第一次转账成功，但响应失败，这个时候的 REST 重试将会是灾难性的。
个人理解，在SoapUI工具中，如果发现接口是xml进行响应传输数据，就使用New SOAP Project；其它一律使用New REST Project，比如接口返回是JSON格式的。
参考资料：https://www.soapui.org/learn/tutorials/web-service-example-projects.html