Code Copied

SOAP vs. REST

SOAP vs. REST是一个伪命题,对它们进行直接比较并不恰当,因为SOAP(简单对象访问协议)是一种协议,而REST(表述性状态转移)是一种架构风格

协议和架构是两种完全不同层面的东西,协议是计算机网络中信息交换的规则、标准和约定,其偏向于技术细节和底层;架构则是在系统层面的基准规范、通用性和原则,其偏向于抽象和顶层。
一种协议可以用在不同的架构中,在架构的建设过程中也可以使用多种协议。

但我还是把它们两者拿出来进行比较,因为它们都可以用于构筑Web Service。Web Service的最大作用在于其互操作性,它独立于平台、语言,可以让不同的应用程序互相调用。
通俗地讲,Web Service扫除了远程对象或方法调用的障碍,它是疏通不同应用程序或服务器之间信息沟通的桥梁。

基本概念

在我之前的两篇文章SOAP介绍REST介绍中,我已经较为详细地说明了SOAP和REST的一些概念和渊源。如果您对这两者的概念还不甚清楚,可以先阅读这2篇文章。

SOAP

SOAP可以看作是XML-PRC的升级版本,它是一种轻量的、简单的基于XML的协议,允许应用程序通过HTTP或其它传输协议来交换信息,SOAP是用于访问Web Service的协议。

REST

REST是一种价格风格,不是一个标准。REST定义了一组体系架构原则,它借助HTTP的标准方法(POST,GET,PUT,DELETE),实现了对资源的CRUD操作。

SOAP和REST的比较

一个SOAP客户端像一个桌面应用程序,它和服务端的是紧耦合的。
SOAP客户端和服务端之间维护一个共同的严格的契约。当客户端的调用模型变更时,服务端需要变更契约以适应客户端;当服务端的契约变更时,SOAP客户端也必须手动或自动更新其契约,否则客户端和服务端之间将无法通信。

一个REST客户端更像一个浏览器应用程序,它和服务端是松耦合的。
REST服务端为每个资源提供统一的操作方法,这些操作方法都基于HTTP的标准方法,并且共用一个URI。同样地,REST客户端通过HTTP标准方法和URI操作服务端的资源。
由于客户端的访问方式和REST服务端提供操作的方式高度一致,并且都遵循HTTP的标准,所以当服务端或者客户端的业务逻辑变更时,客户端和服务端的调用基本不需要变更。

下图分别列出了SOAP Web Service和RESTful Web Service的调用方式

image

从另外一个角度看,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中,我们用到它的场景并不多。

ACID事务:数据库必须具备ACID特性,即原子性(Atomic)、一致性(Consistency)、Isolation(隔离性)和持久性(Durability)。中文翻译过来可以叫做“酸性”事务。