CXF系列（五）：soap与rest的比较

前四篇文章我都是围绕着soap来进行CXF的代码编写，但是实际业务中还有一种方式特别流行，他就是rest。本文具体来阐述2者的区别，在之前我们先看两者的定义。

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紧密结合，因为它服务器无状态。

看完定义我们来看看区别

1：SOAP相对REST来说较为重量级，由于采用XML格式的消息体，消息的有效负荷占比较REST常用的JSON少，不过XML消息的好处是较JSON来说更容易为人阅读。

2：SOAP接口是自解释的，采用WSDL进行描述，程序可以基于WSDL进行解释并自动生成SOAP调用代码；REST接口只能通过接口文档进行描述，难以做到程序解释接口定义。

3：SOAP采用HTTP作为传输层协议，对HTTP协议来说服务调用是透明的，防火墙上难以对SOAP进行细粒度的权限控制，也难以使用http的缓存机制提高效率。而REST是标准的HTTP访问，可以充分利用HTTP协议提供的一些好处，例如可以在防火墙上较好地进行权限控制（最小粒度可以基于每个URL的CRUD操作），也可以充分利用缓存提高响应速度和系统的吞吐效率。

4：对于移动程序而言，由于REST的有效负荷占比高于SOAP的XML封装，采用REST接口可以降低程序使用的带宽。

5：根据REST设计原则，接口是无状态的，因此可以简单地通过对服务器进行水平扩展提升服务能力。

6：由于REST是标准的HTTP访问，其适用性更广，web应用，移动应用都可以在不使用第三方库的情况下方便地使用REST接口构造应用程序。

看到这似乎好像REST比SOAP好太多太多，其实不然，他们两者各有千秋，得看你的项目性质来选择。一个很大的有点就是后者支持事务性。尽管 REST 也支持事务，但它并非完整性的而且不具备 ACID。例如，如果我去写一个连接到我的银行的 iPhone 应用那么我当然需要使用 SOAP。上述三点特性都是银行事务所必须的。比如，如果我将资金从一个账户转移到另外一个账户，我需要确定它的完成。如果第一次转账成功，但响应失败，这个时候的 REST 重试将会是灾难性的。SOAP有完善的标准规范和自动化开发工具，REST则更简单，对移动应用更友好。一般来说如果项目是互联网项目，可能对事务要求不高，可以优先考虑REST；如果一些企业级的项目对事务要求高，还是选择SOAP。学习cxf尽量掌握2种方式的实现，而不是去争谁好谁坏，技术都是好的，关键看你怎么用。接下来最后一篇将简单介绍CXF的REST方式！！！