soap和rest两种WebService对比

webservice相关的基础知识

WebService，顾名思义就是基于Web的服务。它使用Web(HTTP)方式，各个平台可以统一的接收和响应外部系统的某种请求，从而实现远程调用。简言之WebService就是一种跨编程语言和跨操作系统平台的远程调用技术。

1. 传统的webservice

1.1 传统的Web Services 框架的核心技术

传统的webservice 包括SOAP ,WSDL 和UDDI ,它们都是以标准的XML 文档的形式表示。

• XML. Extensible Markup Language

  • XML，用于传输格式化的数据，是Web服务的基础。
  • namespace-命名空间。
  • xmlns:itcast=“http://itcast.cn”使用指定名称的命名空间。

• SOAP (“Simple Object Access Protocol”的缩写)是Web Services 的通信协议。SOAP是一种简单的、轻量级的基于XML 的机制，用于在网络应用程序之间进行结构化数据交换。SOAP包括三部分:一个定义描述消息内容的框架的信封，一组表示应用程序定义的数据类型实例的编码 规则，以及表示远程过程调用和响应的约定。SOAP是在HTTP协议上传输XML文件的

  soap协议主要特点及作用就是：

  1. 传递信息的格式为XML.这就使Web Services能够在任何平台上，用任何语言进行实现。

  2. 规定了远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。

  3. 实现参数类型和XML格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个Person对象。怎样用XML来表示一个对象参数，也是SOAP所定义的范围。

• WSDL表示WEB服务说明语言。WSDL文件是一个XML 文档，用于说明一组SOAP消息以及如何交换这些消息。当实现了某种服务的时候(如：股票查询服务)，为了让别的程序调用，必须告诉大家服务接口。例如： 服务名称，服务所在的机器名称，监听端口号，传递参数的类型，个数和顺序，返回结果的类型等等。这样别的应用程序才能调用该服务。WSDL协议就是规定了 有关Web Services描述的标准。
• UDDI(“Universal Description， Discovery，and Integration”的缩写)提供一种发布和查找服务描述的方法。UDDI 数据实体提供对定义业务和服务信息的支持。WSDL 中定义的服务描述信息是UDDI注册中心信息的补充

1.2 Web Services的工作流程

1. Web Services 服务提供方通过WSDL描述所提供的服务，并将这一描述告知Web Services 注册服务器。
2. 注册服务器依据WSDL 的描述，依照UDDI的协定更新服务目录并在Internet 上发布。
3. 用户在使用Web Services 前先向注册服务器发出请求，获得Web Services 提供者的地址和服务接口信息。
4. 使用SOAP 协议与Web Services 提供者建立连接,进行通信。

2. RESTful WebService

由于Restful风格越来越流行，sun公司也推出了** RESTful WebService 的官方规范： JAX-RS ，全称：

Java API for RESTful WebService。作为SOAP模式 的替代者，REST(是“Representational State Transfer”的缩写)是一种轻量级的Web Services架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁（因为只传输代表数据的 xml 或 json ，没有额外的 xml 包装），可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速 度，性能、效率和易用性上都优于SOAP协议。

2.1 RESTful Web Services是什么

​ REST是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。在RESTful系统中，服务器利用URI暴露资源，客户端使用四个Http谓词来访问资源。由于客户端接收了资源，他们被置于某种状 态。当他们访问一个新的资源，通常是点击下一个连接，他们改变了，或者说是过渡了他们的状态。为了工作，REST假设资源是能够使用普遍的标准语法来代表的。

传统的Web应用大都是B/S架构，它包括了如下一些规范。

１.客户－服务器：这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。

2.无状态性： 无状态性是在客户－服务器约束的基础上添加的又一层规范。它要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上 下文中，因此增加了在一系列request中发送重复数据的开销，严重的降低了效率。

3.缓存： 为了改善无状态性带来的网络的低效性，我们添加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信 息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。

B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST！

REST在原有的架构上增加了三个新规范：统一接口、分层系统和按需代码。

１.统一接口：REST架构风格的核心特征就是强调组件之间有一个统一的接口， 这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是 解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性；并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效的转移大粒 度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。

２.分层系统：分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。

３.按需代码：REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。

​ REST描述了一种设计Web应用的架构风格，它是一组架构约束条件和原则，满足这些约束条件和原则的应用程序或设计就是 RESTful风格的。而符合RESTful风格的Web Services，就是我们所说的RESTful Web Services。

2.2 REST得原则

REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。

REST中的资源所指的不是数据，而是数据和表现形式的组合， 比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而由于它们的表现形式不同，所以被归为不同的资源，这也就是为什 么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式，txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。

REST是基于HTTP协议的，任何对资源的操作行为都是通过HTTP协议来实现。以往的Web开发大多数用的都是HTTP协议中的GET和POST方法，对其他方法很少使用，这实际上是因为对HTTP协议认识片面的理解造成的。HTTP不仅仅是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。它不仅仅能对互联网资源进行唯一定位，而且还能告诉我们如何对该资源进行操作。HTTP把 对一个资源的操作限制在4个方法以内：GET，POST，PUT和DELETE，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，执行这 些操作的时候URI是没有变化的，这和以往的Web开发有很大的区别。正由于这一点，极大的简化了Web开发，也使得URI可以被设计成更为直观的反映资 源的结构，这种URI的设计被称作RESTful的URI，这为开发人员引入了一种新的思维方式：通过URL来设计系统结构。当然，这种设计方式对一些特 定情况也是不适用的，也就是说不是所有的URI都可以RESTful的。

REST之所以可以提高系统的可伸缩性，就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束，做分布式和集群的时候就更 为简单，也可以让系统更为有效的利用缓冲池(Pool），并且由于服务器端不需要记录客户端的一系列访问，也减轻了服务器端的性能开销。

REST提出了如下设计准则

• 资源由URI来指定: 在Web应用中，所有的事物都应该拥有唯一的ID，代表ID的统一概念是：URI。URI构成了一个全局命名空间，使用URI标识你的关键资源意味着它们获得了一个唯一、全局的ID。

• 显式的使用HTTP方法: REST 要求开发人员显式地使用 HTTP 方法，并且使用方式与协议定义一致。 这个基本 REST 设计原则建立了创建、读取、更新和删除（create, read, update, and delete，CRUD）操作与 HTTP 方法之间的一对一映射。 根据此映射：

  • 若要在服务器上创建资源，应该使用 POST 方法。
  • 若要检索某个资源，应该使用 GET 方法。
  • 若要更改资源状态或对其进行更新，应该使用 PUT 方法。
  • 若要删除某个资源，应该使用 DELETE 方法。
    CRUD原则：对于资源只需要四种行为：Create(创建)、Read(读取)、 Update(更新)和Delete(删除)就可以完成对其操作和处理

除了抽象操作为基础的CRUD。所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计

• 资源多重表述: 针对不同的需求提供资源多重表述。这里所说的多重表述包括XML、JSON、HTML等。即服务器端需要向外部提供多种格式的资源表述，供不同的客户端使用。比如移动应用可以使用XML或JSON和服务器端通信，而浏览器则能够理解HTML。
• 无状态: 对服务器端的请求应该是无状态的，完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理，可能是软件需要升级重启——如果这个客户端访问了从这台服务器接收的链接，它不会察觉到后台的服务器已经改变了。
  　　REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在 Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数(例如编码，错误码等)都置之不顾。

REST不仅仅是一种崭新的架构，它带来的更是一种全新的Web开发过程中的思维方式： 通过URL来设计系统结构。在REST中，所有的URL都对应着资源，只要URL的设计是良好的，那么其呈现的系统结构也就是良好的。这点和 TDD(Test Driven Development)很相似，它是通过测试用例来设计系统的接口，每一个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能，而只需要 把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URL设计系统结构的方式类似，我们只需要根据需求设计出合理地URL，这些 URL不一定非要链接到指定的页面或者完成一些行为，只要它们能够直观的表现出系统的用户接口。根据这些URL，我们就可以方便的设计系统结构。从 REST架构的概念上来看，所有能够被抽象成资源的东西都可以被指定为一个URL，而开发人员所需要做的工作就是如何能把用户需求抽象为资源，以及如何抽象的精确。 因为对资源抽象的越为精确，对REST的应用来说就越好，这个和传统MVC开发模式中基于Action的思想差别就非常大。设计良好的URL，不但对于开 发人员来说可以更明确的认识系统结构，对使用者来说也方便记忆和识别资源，因为URL足够简单和有意义。按照以往的设计模式，很多URL后面都是一堆参 数，对于使用者来说也是很不方便的。

既然REST这么好用，那么是不是所有的Web应用都能采取此种架构呢？答案是否定的。我 们知道，直到现在为止，MVC(Model-View-Controller)模式依然是Web开发最普遍的模式，绝大多数的公司和开发人员都采取此种架 构来开发Web应用，并且其思维方式也停留于此。MVC模式由数据，视图和控制器构成，通过事件(Event)触发Controller来改变Model 和View。加上Webwork,Struts等开源框架的加入，MVC开发模式已经相当成熟，其思想根本就是基于Action来驱动。从开发人员角度上 来说，贸然接受一个新的架构会带来风险，其中的不确定因素太多，并且REST新的思维方式是把所有用户需求抽象为资源，这在实际开发中是比较难做到的，因 为并不是所有的用户需求都能被抽象为资源，这样也就是说不是整个系统的结构都能通过REST的来表现。所以在开发中，我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC， 因为这适合绝大多数的Web应用开发，开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式，而对其它需求采取MVC开发即可。这里需要提到的就是ROR(Ruby on Rails)框架，这是一个基于Ruby语言的越来越流行的Web开发框架，它极大的提高了Web开发的速度。更为重要的是，ROR(从1.2版本起)框 架是第一个引入REST做为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的 REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好的构建Web应用。

3. RESTful Web Services与基于SOAP的Web Services比较

基于SOAP的Web Services也是解决异构系统间通信问题的常用方案，那么，RESTful Web Services相对于基于SOAP 的Web Services，有什么优势呢？或者说，我们为什么要开始学习RESTful Web Services，使用已经流行很久的基于SOAP的Web Services不就好了么？

• RESTful Web Services接口更易于使用

​ RESTful Web Services使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 来抽象所有 Web 系统的服务能力，而不同的是，SOAP 应用都通过定义自己个性化的接口方法来抽象 Web 服务。相对来说，RESTful Web Services接口更简单。

​ RESTful Web Services使用标准的 HTTP 方法的优势，从大的方面来讲：标准化的 HTTP 操作方法，结合其他的标准化技术，如 URI，HTML，XML 等，将会极大提高系统与系统之间整合的互操作能力。尤其在 Web 应用领域，RESTful Web Services所表达的这种抽象能力更加贴近 Web 本身的工作方式，也更加自然。

• 无状态性

​ HTTP 协议从本质上说是一种无状态的协议，客户端发出的 HTTP 请求之间可以相互隔离，不存在相互的状态依赖。基于 HTTP 的 ROA，以非常自然的方式来实现无状态服务请求处理逻辑。对于分布式的应用而言，任意给定的两个服务请求 Request 1 与 Request 2, 由于它们之间并没有相互之间的状态依赖，就不需要对它们进行相互协作处理，其结果是：Request 1 与 Request 2 可以在任何的服务器上执行，这样的应用很容易在服务器端支持负载平衡 (load-balance)。

• 安全操作与幂指相等特性

​ HTTP 的 GET、HEAD 请求本质上应该是安全的调用，即：GET、HEAD 调用不会有任何的副作用，不会造成服务器端状态的改变。对于服务器来说，客户端对某一 URI 做 n 次的 GET、HAED 调用，其状态与没有做调用是一样的，不会发生任何的改变。

​ HTTP 的 PUT、DELTE 调用，具有幂指相等特性 , 即：客户端对某一 URI 做 n 次的 PUT、DELTE 调用，其效果与做一次的调用是一样的。HTTP 的 GET、HEAD 方法也具有幂指相等特性。

​ HTTP 这些标准方法在原则上保证你的分布式系统具有这些特性，以帮助构建更加健壮的分布式系统。

• RESTful Web Services更容易实现缓存

​ 众所周知，对于基于网络的分布式应用，网络传输是一个影响应用性能的重要因素。如何使用缓存来节省网络传输带来的开销，这是每一个构建分布式网络应用的开发人员必须考虑的问题。

​ HTTP 协议带条件的 HTTP GET 请求 (Conditional GET) 被设计用来节省客户端与服务器之间网络传输带来的开销，这也给客户端实现 Cache 机制 ( 包括在客户端与服务器之间的任何代理 ) 提供了可能。HTTP 协议通过 HTTP HEADER 域：If-Modified-Since/Last- Modified，If-None-Match/ETag 实现带条件的 GET 请求。

​ REST 的应用可以充分地挖掘 HTTP 协议对缓存支持的能力。当客户端第一次发送 HTTP GET 请求给服务器获得内容后，该内容可能被缓存服务器 (Cache Server) 缓存。当下一次客户端请求同样的资源时，缓存可以直接给出响应，而不需要请求远程的服务器获得。而这一切对客户端来说都是透明的。

• 一些缺陷：

先说成熟度，SOAP发展到现在虽然已经背离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的Web Services都能够较好的互通。

反观REST，相比于SOAP的权威性协议规范，REST实现的各种协议只能算是私有协议，当然需要遵循REST的思想，在兼容性方面会差很多。

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

再说效率，SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础。REST被人们的重视，其实很大原因是 源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了HTTP最初的应用协议设计理念。

同时， REST还很好的融合Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有JSON，RSS，等形式。

因此，相对于SOAP， REST的效率更胜一筹。

​ 最后说安全性，SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持。 REST没有任何规范对于安全方面作说明。

4. Soap WebService 和Restful WebService 得应用场景。

4.1 使用Restful WebService的场景。

• 带宽资源有限
• 无状态调用。如果不需要维护从一个请求到另一个请求的信息状态，则应使用REST。如果您需要一个适当的信息流，其中一个请求中的某些信息需要流入另一个请求中，那么SOAP更适合于此目的。
• 缓存。如果需要缓存大量请求，那么REST是理想的解决方案。有时，客户端可以多次请求相同的资源。这可以增加发送到服务器的请求的数量。通过实现缓存，可以将最频繁的查询结果存储在中间位置。因此，无论何时客户端请求资源，它都会首先检查缓存。如果资源存在，那么它将不会继续到服务器。
• 易于编码。Rest的代码实现要比Soap实现简单的多