WebService之REST和SOAP的比较

阅读文本大概需要 9 分钟。

在 SOA 的基础技术实现方式中 WebService 占据了很重要的地位，通常我们提到 WebService 第一想法就是 SOAP 消息在各种传输协议上交互。近几年 REST 的思想伴随着 SOA 逐渐被大家接受，同时各大网站不断开放 API 提供给开发者，也激起了 REST 风格 WebService 的热潮。

SOAP

什么是 SOAP，我想不用多说，google 一把满眼都是。其实 SOAP 最早是针对 RPC 的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http，SMTP等）。但是随着 SOAP 作为 WebService 的广泛应用，不断地增加附加的内容，使得现在开发人员觉得 SOAP 很重，使用门槛很高。在 SOAP 后续的发展过程中，WS-*系列协议的制定，增加了 SOAP 的成熟度，也给 SOAP 增加了负担。

REST

REST 其实并不是什么协议也不是什么标准，而是将 Http 协议的设计初衷作了诠释，在 Http 协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP 类型的 WebService 就是最好的例子，SOAP 消息完全就是将Http 协议作为消息承载，以至于对于 Http 协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是 Http 协议。Http 协议所抽象的 get,post,put,delete 就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的 Http 协议就可以实现，开发者也会受益于这种轻量级的协议。

REST 的思想有几个关键点

1. 面向资源的接口设计

所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时 URI 的设计也是体现了对于资源的定位设计。后面会提到有一些网站的 API 设计说是 REST 设计，其实是RPC-REST 的混合体，并非是 REST 的思想。

2. 抽象操作为基础的 CRUD

这点很简单，Http 中的 get，put，post，delete 分别对应了read，update，create，delete 四种操作，如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于现在的一些复杂的业务服务接口设计，可能这样的抽象未必能够满足。其实这也在后面的几个网站的 API 设计中暴露了这样的问题，如果要完全按照 REST 的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。

3. Http 是应用协议而非传输协议

这点在后面各大网站的 API 分析中有很明显的体现，其实有些网站已经走到了 SOAP 的老路上，说是 REST 的理念设计，其实是作了一套私有的 SOAP 协议，因此称之为 REST 风格的自定义SOAP 协议。

4. 无状态，自包含

这点其实不仅仅是对于 REST 来说的，作为接口设计都需要能够做到这点，也是作为可扩展和高效性的最基本的保证，就算是使用SOAP 的 WebService 也是一样。

REST vs SOAP

成熟度

SOAP 虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过 SOAP 来交互的 web service 都能够较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有作很细致的规定，导致还是需要作部分修正）。

REST 国外很多大网站都发布了自己的开发 API，很多都提供了SOAP 和 REST 两种 Web Service，根据调查部分网站的 REST 风格的使用情况要高于 SOAP。但是由于 REST 只是一种基于 Http 协议实现资源操作的思想，因此各个网站的 REST 实现都自有一套，在后面会讲诉各个大网站的 REST API 的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于 SOAP 发布的 web service，但统一通用方面远远不及 SOAP。由于这些大网站的 SP 往往专注于此网站的 API 开发，因此通用性要求不高。

由于没有类似于 SOAP 的权威性协议作为规范，REST 实现的各种协议仅仅只能算是私有协议，当然需要遵循 REST 的思想，但是这样细节方面有太多没有约束的地方。REST 日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。

总的来说 SOAP 在成熟度上优于 REST。

效率和易用性

SOAP 协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于 SOAP 由于各种需求不断扩充其本身协议的内容，导致在 SOAP 处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。

REST 被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了 Http 最初的应用协议设计理念。同时，在我看来 REST 还有一个很吸引开发者的就是能够很好的融合当前 Web2.0 的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的 mashup 各种资源信息。

因此在效率和易用性上来说，REST 更胜一筹。

安全性

这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全已经被提到了很高的高度，特别是作为外部接口给第三方调用，安全性可能会高过业务逻辑本身。

SOAP 在安全方面是通过使用 XML-Security 和 XML-Signature 两个规范组成了 WS-Security 来实现安全控制的，当前已经得到了各个厂商的支持，.net，php，java 都已经对其有了很好的支持（虽然在一些细节上还是有不兼容的问题，但是互通基本上是可以的）。

REST 没有任何规范对于安全方面作说明，同时现在开放 REST 风格 API 的网站主要分成两种，一种是自定义了安全信息封装在消息中（其实这和 SOAP 没有什么区别），另外一种就是靠硬件SSL 来保障,但是这只能够保证点到点的安全，如果是需要多点传输的话 SSL 就无能为力了。

应用设计与改造

我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让 REST 的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照 REST 的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照 REST 的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入 function 的名称作为参数，这就明显已经违背了REST本身的设计思路。而 SOAP 本身就是面向 RPC 来设计的，开发人员十分容易接受，所以不存在什么适应的过程。

总的来说，其实还是一个老观念，适合的才是最好的。

技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST 和 SOAP 各自都有自己的优点，同时如果在一些场景下如果去改造 REST，其实就会走向 SOAP（例如安全）。

REST 对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而 SOAP 的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。

同时很重要一点就是不要扭曲了 REST 现在很多网站都跟风去开发 REST 风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

一条迷途的咸鱼，

总有一天会游向属于它的天地！