SOAP Webservice和RESTful Webservice

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以下降开发的复杂性，提升系统的可伸缩性。REST提出设计概念和准则为：

1.网络上的全部事物均可以被抽象为资源(resource)
2.每个资源都有惟一的资源标识(resource identifier)，对资源的操做不会改变这些标识
3.全部的操做都是无状态的

REST简化开发，其架构遵循CRUD原则，该原则告诉咱们对于资源(包括网络资源)只须要四种行为：建立，获取，更新和删除就能够完成相关的操做和处理。您能够经过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，而且针对这些资源而执行的操做是经过 HTTP 规范定义的。其核心操做只有GET,PUT,POST,DELETE。

因为REST强制全部的操做都必须是stateless的，这就没有上下文的约束，若是作分布式，集群都不须要考虑上下文和会话保持的问题。极大的提升系统的可伸缩性。

对于SOAP Webservice和Restful Webservice的选择问题，首先须要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操做方法和操做对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源，只要咱们要操做的对象能够抽象为资源便可以使用REST架构风格。

若是从这个意义上讲，是否使用REST就须要考虑资源自己的抽象和识别是否困难，若是自己就是简单的相似增删改查的业务操做，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并非一个简单的事情。好比校验用户等级，转帐，事务处理等，这些每每并不容易简单的抽象为资源。

其次若是有严格的规范和标准定义要求，并且前期规范标准须要指导多个业务系统集成和开发的时候，SOAP风格因为有清晰的规范标准定义是明显有优点的。咱们能够在开始和实现以前就严格定义相关的接口方法和接口传输数据。

简单数据操做，无事务处理，开发和调用简单这些是使用REST架构风格的优点。而对于较为复杂的面向活动的服务，若是咱们仍是使用REST，不少时候都是仍然是传统的面向活动的思想经过转换工具再转换获得REST服务，这种使用方式是没有意义的。

正如另一篇文章里面谈到的，REST核心是url和面向资源，url代替了原来复杂的操做方法。REST容许咱们经过url设计系统，就像测试驱动开发使用测试用例设计类接口同样。全部能够被抽象为资源的东西均可以使用RESTful的url，当咱们以传统的用SOAP方式实现的一个查询订单服务的时候能够看到，这个服务首先存在输入的查询条件，而后才是输出结果集。那么对于相似场景要使用REST，不可避免的会将传统的SOAP服务拆分为一个HTTP POST操做和一个HTTP GET操做。前面是输入，然后面是输出。

使用REST的关键是如何抽象资源，抽象的越精确，对REST的应用越好。如何进行抽象，面向资源的设计和传统的面向结构和对象设计区别，资源和对象，数据库表之间的差异是另一个在分析设计时候要考虑的问题。在REST分析设计中如何改变传统的SOAP分析设计思想又是一个重要问题。


在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也是同样。

SOAP Webservice和RESTful Webservice的比较

成熟度(总的来讲SOAP在成熟度上优于REST)

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往后的发展所走向规范也会直接影响到这部分的设计是否可以有很好的生命力。

效率和易用性(REST更胜一筹)

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

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

安全性：

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

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

REST没有任何规范对于安全方面做说明，同时如今开放REST风格API的网站主要分红两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另一种就是靠硬件SSL来保障,可是这只可以保证点到点的安全，若是是须要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，实际上是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。将来REST规范化和通用化过程当中的安全是否也会采用这两种规范，是未知的，可是加入的越多，REST失去它高效性的优点越多。

应用设计与改造：

咱们的系统要么就是已经有了那些须要被发布出去的服务，要么就是刚刚设计好的服务，可是开发人员的传统设计思想让REST的形式被接受还须要一点时间。同时在资源型数据服务接口设计上来讲按照REST的思想来设计相对来讲要容易一些，而对于一些复杂的服务接口来讲，可能强要去按照REST的风格来设计会有些牵强。这一点其实能够看看各大网站的接口就能够知道，不少网站还要传入function的名称做为参数，这就明显已经违背了REST自己的设计思路。而SOAP自己就是面向RPC来设计的，开发人员十分容易接受，因此不存在什么适应的过程。总的来讲，其实仍是一个老观念，适合的才是最好的

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

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

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