浅谈 SOAP Webservices 与 Restful Webservices 区别
一 REST：
REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。
REST提出设计概念和准则为：
1.网络上的所有事物都可以被抽象为资源(resource)
2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识
3.所有的操作都是无状态的
REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,PUT,POST,DELETE。
由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。
二 SOAP
SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容。
SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。
而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。
如何确定使用REST：
若本身只是简单的CRUD业务操作，那么抽象资源就比较容易。
而对于复杂的业务活动抽象资源并不是一个简单的事情，比如校验用户等级，转账，事务处理等。
如何确定使用SOAP：
若有严格的规范和标准定义要求，且前期需要指导多个业务系统集成和开发的时，
因SOAP风格有清晰的规范标准定义，SOAP更适合。
我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。
一句话：
简单数据操作，无事务处理，开发和调用简单使用REST架构风格较好。
再者：
REST核心是url和面向资源，url代替了原来复杂的操作方法。
REST允许我们通过url设计系统，就像测试驱动开发使用测试用例设计类接口一样。
所有可以被抽象为资源的东西都可以使用RESTful的url。
REST关键：
使用REST的关键是如何抽象资源，抽象的越精确，对REST的应用越好。
———————————————————————————————————————
三 REST思想
1．面向资源的接口设计
所有的接口设计都是针对资源来设计的（包括操作也是一种资源）。
URI的设计也是体现了对于资源的定位设计。
2．抽象操作为基础的CRUD
Http中的get,put,post,delete分别对应了read,update,create,delete四种操作
如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于复杂的业务接口，未必能够满足。
完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。
3．Http是应用协议而非传输协议
部分认为：REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。
4．无状态，自包含
接口设计都需做到这点，不仅仅是REST，也是作为可扩展和高效性的最基本的保证，SOAP也类似。
RESTful webService
RESTful 服务遵循REST(Representational State Transfer)的架构风格，中文翻译为：表现层状态转化
对于所有的CRUD(Create/Read/Update/Delete),RESTful架构基于HTTP的简单动作（POST,GET,,PUT,DELETE）来实现。它简单而且轻巧，比基于SOAP消息的WebService简单的多的一种轻量级Web服务，RESTful WebService是没有状态的，发布和调用都非常的轻松容易。
表现层（Representation）
"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；
URI只代表资源的实体，不代表它的形式。URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。
状态转化（State Transfer）：
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
RESTful架构有一些典型的设计误区：
1、URI包含动词：因为"资源"表示一种实体，应该是名词，URI不应该有动词，动词应该放在HTTP协议中；
2、URI中加入版本号：因为不同的版本，可以理解成同一种资源的不同表现形式，应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分；
例子：
1）：创建Class Library Project，项目名为RestService
引用System.ServiceModel; System.ServiceModel.Web;
IRestServiceDemo代码如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using System.ServiceModel.Web;
namespace RestService
{
[ServiceContract(Name = "RestSercice")]
public interface IRestServiceDemo
{
[OperationContract]
[WebGet(UriTemplate = Routing.GetClientRouting, BodyStyle = WebMessageBodyStyle.Bare)]
string GetNameById(string id);
[OperationContract]
[WebGet(UriTemplate = Routing.GetClientRouting2, BodyStyle = WebMessageBodyStyle.Bare)]
string GetAgeById(string id);
}
public static class Routing
{
public const string GetClientRouting = "/Client/{id}";
public const string GetClientRouting2 = "/Client/zhj/{id}";
}
}
RestService实现代码如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using System.ServiceModel.Activation;
namespace RestService
{
[ServiceBehavior(InstanceContextMode =
InstanceContextMode.Single,ConcurrencyMode =
ConcurrencyMode.Single,IncludeExceptionDetailInFaults = true)]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class RestServiceDemo:IRestServiceDemo
{
public string GetNameById(string id)
{
string returnStr = id + "name is John" ;
return returnStr;
}
public string GetAgeById(string id)
{
string returnStr = id + "age is 18 years old";
return returnStr;
}
}
}
2）：创建Console Application项目，项目名为HostService
引用System.ServiceModel; System.ServiceModel.Web;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using RestService;
using System.ServiceModel.Web;
namespace HostService
{
class Program
{
static void Main(string[] args)
{
RestServiceDemo restServiceDemo = new RestServiceDemo();
WebServiceHost serviceHost = new WebServiceHost(restServiceDemo,new Uri("http://localhost:8000/MyService"));
serviceHost.Open();
Console.ReadKey();
serviceHost.Close();
}
}
}
3）：运行Host程序，在浏览器中输入对应Service的Url
http://localhost:8000/MyService/Client/3 输出：3 name is John;
http://localhost:8000/MyService/Client/zhj/3 输出：3 age is 18 years old;
四 SOAP Webservice和RESTful Webservice的比较
1.成熟度(总的来说SOAP在成熟度上优于REST)
SOAP对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。
REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，
但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套。
REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想。
2.效率和易用性(REST更胜一筹)
SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，
WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP
处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。
这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，
同时也最大限度的利用了Http最初的应用协议设计理念。
同时，REST很好的融合当前Web2.0的很多前端技术来提高开发效率。
例如:很多大型网站开放的REST风格的API都会有多种返回形式（XML,JSON,RSS,ATOM）等形式。
3.安全性
SOAP在安全方面使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，
当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持。
REST 开放REST风格API的网站主要分成两种:
一种是自定义了安全信息封装在消息中，
另外一种就是靠硬件SSL来保障,这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。
安全这块其实也是一个很大的问题。
五 应用设计与改造
我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入function的名称作为参数，这就明显已经违背了REST本身的设计思路。而SOAP本身就是面向RPC来设计的，开发人员十分容易接受，所以不存在什么适应的过程。总的来说，其实还是一个老观念，适合的才是最好的
技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。
同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。
