关于restful:RESTful和SOAP的区别

一、Web Service
　　Web Service服务通常被定义为一组模块化的API，它们能够通过网络进行调用,来执行近程零碎的申请服务。Web service是一个平台独立的，低耦合的，自蕴含的、基于可编程的web的应用程序，可应用凋谢的XML规范来形容、公布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。各应用程序通过网络协议和规定的一些规范数据格式（Http，XML，Soap)来拜访Web Service，通过Web Service外部执行失去所需后果。根据Web Service标准施行的利用之间， 无论它们所应用的语言、 平台或外部协定是什么， 都能够相互交换数据。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。

　　实际上，Web Service的次要指标是跨平台的可互操作性。为了达到这一指标，Web Service齐全基于XML（可扩大标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的规范，是创立可互操作的、分布式应用程序的新平台。Web service平台必须提供一套规范的类型零碎，用于沟通不同平台、编程语言和组件模型中的不同类型零碎。

1. 根本元素

　　Web Service的三种根本元素：SOAP、WSDL和UDDI。

　　SOAP 是一种基于XML协定、用于扩散或散布的环境中替换信息的简略协定。

　　WSDL ( 网络服务描述语言，Web Services Description Language）是一门基于 XML 的语言，用于形容 Web Services 以及如何对它们进行拜访。web service 描述语言 (WSDL) 就是这样一个基于 XML 的语言，用于形容 web service 及其函数、参数和返回值。因为是基于 XML 的，既可供人浏览，也可应用工具生成调用相应 web service 的代码。实例如下：

View Code
　　UDDI ( 通用形容、发现与集成服务，Universal Description, Discovery and Integration) UDDI 是一种目录服务，企业能够应用它对 Web services 进行注册和搜寻。UDDI 是一种由 WSDL 形容的 ，用于存储无关 web services 的信息的目录，应用 SOAP、XML、HTTP 和 DNS 协定。UDDI是一种标准，它次要提供基于Web服务的注册和发现机制，为Web服务提供三个重要的技术支持：①规范、通明、专门形容Web服务的机制；②调用Web服务的机制；③能够拜访的Web服务注册核心。

　　UDDI实现了一组可公开拜访的接口，通过这些接口，网络服务能够向服务信息库注册其服务信息、服务需求者能够找到扩散在世界各地的网络服务。如果行业公布了一个用于航班比率检测和预订的 UDDI 规范，航空公司就能够把它们的服务注册到一个 UDDI 目录中。而后旅行社就可能搜寻这个 UDDI 目录以找到航空公司预订界面。当此界面被找到后，旅行社就可能立刻与此服务进行通信，这样因为它应用了一套定义良好的预订界面。UDDI 并不像 WSDL 和 SOAP 一样深入人心，因为很多时候，使用者晓得 Web 服务的地位（通常位于公司的企业内部网中）。

2. 利用场合

   a. 逾越防火墙通信

　 客户端和服务器端之间通信都会有防火墙或者代理服务器。传统的实现相互通信的办法是在分布式对象，如DCOM、CORBA之间进行互相的近程过程调用（TCP/IP），而应用web service应用程序能够基于HTTP和XML等规范替换信息，从而逾越防火墙。

b. 应用程序集成

企业里常常要把不同平台不同语言编写的各种程序集成起来，为了可能让公司各部门之间进行通信，须要将公司外部的应用程序和商业过程集成在一起。当被包装成一个或一组Web服务之后，任何应用程序实践上都能够通过SOAP音讯与其进行通信。

c. 软件复用

　 Web服务实现了业务级别的软件复用，例如在B2B的集成中，各企业之间通过相互调用Web服务，实现了Web服务的共享。

3. Web Service和Socket的比照

   a. Socket是基于TCP/IP的传输层协定。

     Web Service是基于HTTP协定+XML传输数据（HTTP是基于TCP的应用层协定）。

   b. Socket接口通过流传输，不反对面向对象。

     Web Service接口反对面向对象，将对象序列化后通过流传输。它不需针对数据流的发送和接管进行解决，是一种跨平台的面向对象近程调用技术。

   c. Socket实用于高性能大数据的传输。因为数据传输的格局不固定，socket通信的接口协议须要自定义，程序员须要本人去解析发送和接管的数据。

     Web Service实用于没有性能要求状况下且数据传输量小，举荐在公开接口上应用webservice，因为soap协定是规范的。
   

二、SOAP
　　SOAP (Simple Object Access Protocol)是一种基于XML协定、用于扩散或散布的环境中替换信息的简略协定，可使应用程序在 HTTP 之上进行信息替换。应用Soap的目标是定义如何调用近程终端的服务（办法），Soap中用多个NameSpace规范来区别各个近程服务。SOAP偏差于面向流动，有严格的标准和规范，包含平安，事务等各个方面的内容。SOAP强调操作方法和操作对象的拆散，有WSDL文件标准和XSD文件别离对其定义。SOAP定义了一整套简单的标签，以形容调用的近程过程、参数、返回值和出错信息等等。

　　对于利用程序开发来说，使程序之间进行因特网通信是很重要的。以往的应用程序通过应用近程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信，然而RPC会产生兼容性以及平安问题（采纳CORBA做为企业级中间件，不同零碎之间的通信只能用称为&＃8221;桥&＃8221;的技术(Bridge)来解决，这些&＃8221;桥&＃8221;由软件厂商提供给开发者应用，而且不同版本间的CORBA也不兼容，一个桥只具备绝对狭隘范畴内的互通作用）；防火墙和代理服务器通常会阻止此类流量。通过 HTTP 在应用程序间通信是更好的办法，因为 HTTP 失去了所有的因特网浏览器及服务器的反对。SOAP 就是被发明进去实现这个工作的。SOAP 通过建设 HTTP 连贯隧道来部署本人的协定：SOAP要求把申请参数组织在XML文档中，该文档而后被放到HTTP POST申请体中发送到运行在Web主机基于SOAP 的Web服务。SOAP提供了一种规范的办法，使得运行在不同的操作系统并应用不同的技术和编程语言的应用程序能够相互进行通信。

１. SOAP 构建模块

　　SOAP音讯基本上是从发送端到接收端的单向传输，它们经常联合起来执行相似于申请/应答的模式。不须要把SOAP音讯绑定到特定的协定，SOAP能够运行在任何其余传输协定（HTTP、SMTP、FTP等）上。另外，SOAP提供了规范的RPC办法来调用Web Service以申请/响应模式运行。

　 a. SOAP基于XML语言和XSD规范，其定义了一套编码规定，该规定定义如何将数据表示为音讯，怎么通过HTTP协定来传输SOAP音讯，包含四局部：

SOAP信封（Envelope）：定义了一个框架，该框架形容了音讯中的内容是什么，包含音讯的内容、发送者、接收者、解决者以及如何解决这些音讯。
SOAP编码规定：它定义了一种系列化机制，用于替换应用程序所定义的数据类型的实例。
SOAP RPC示意：它定义了用于示意近程过程调用和应答协定。
SOAP绑定：它定义了一种应用底层传输协定来实现在节点间替换SOAP信封的约定。
　 b. SOAP音讯的组成部分：

必须的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 音讯
可选的 Header 元素，蕴含头部信息
必须的 Body 元素，蕴含所有的调用和响应信息
可选的 Fault 元素，提供无关在解决此音讯所产生谬误的信息
申明上述元素的命名空间：http://www.w3.org/2001/12/soa&＃8230;
申明SOAP 编码和数据类型的命名空间：http://www.w3.org/2001/12/soa&＃8230;
语法规定：SOAP 音讯必须应用XML编码、SOAP Envelope和Encoding命名空间，且SOAP不能蕴含DTD援用和XML解决指令

2. SOAP实例

SOAP 申请：
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

  
    IBM
  

SOAP 响应：
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

  
    34.5
  

3. 长处

易用：是因为它的音讯是基于xml并封装成了合乎http协定，因而,它合乎任何路由器、 防火墙或代理服务器的要求。
灵便：SOAP极具拓展性，无需中断已有的应用程序, SOAP客户端、服务器和协定本身都能倒退。而且SOAP能极好地反对两头介质和层次化的体系结构。
跨语言：soap能够应用任何语言来实现，只有发送正确的soap申请即可。
跨平台：基于soap的服务能够在任何平台无需批改即可失常应用。
安全性：SOAP能够看着是一个重量级的协定，基于xml，SOAP在平安方面是通过应用XML-Security和XML-Signature两个标准组成了WS-Security来实现安全控制的，以后曾经失去了各个厂商的反对，.net ，php ，java 都曾经对其有了很好的反对 。这是REST单薄的中央。

4. 毛病

SOAP目前实现在HTTP/HTTPS通信协议之上，不过HTTP的这种申请/响应式模型并不一定适宜所有场合，因而SOAP依然须要定义其余的通信协议。
目前SOAP的规范没有定义如何传递近程对象，因而所有的信息都必须转换为数值来传递，这会升高效率，以及在开发分布式Web利用零碎中会产生一些问题。
SOAP须要XML解析器来解决封装的信息，然而每一种SOAP实现应用的XML解析器可能不同，这会造成一些应用DOM模式的XML解析器无奈解决大量 的SOAP封包。此外这种解析器也可能应用大量的资源而造成零碎惨重的负荷，升高SOAP/Web Service的延展性和执行效率。

三、REST
　　REST是一种架构格调，其外围是面向资源，这些资源能够是文本文件、视频或动静业务数据，资源由对立资源标识符（Universal Resource Identifier，URI）标识 。REST服务器只是提供资源，REST客户端可拜访和批改的资源。REST个别应用HTTP作为它的传输协定，因为HTTP提供了一些很好用的个性，如HTTP动词，状态码和头部信息。RESTful Web 服务是轻量级的，高度可伸缩和可保护的，通常用于给 Web 应用程序创立 APIs。

１. REST设计概念和准则

网络上的所有事物都能够被形象为资源(resource)
每一个资源都有惟一的资源标识(resource identifier)，对资源的操作不会扭转这些标识
所有的操作都是无状态的

2. REST架构中罕用的 HTTP 办法

GET &＃8211; 提供资源的只读拜访。（只读且平安）　&＃8211; 幂等性：反复执行后果不变，就算在失败当前。安全性：是否扭转服务端的状态。
PUT &＃8211; 用于创立一个新资源。（幂等不平安，因其幂等性可用于金钱相干的操作）　　
DELETE &＃8211; 用于移除一个资源。（幂等）
POST &＃8211; 用于更新现有资源或者创立一个新资源。（不幂等不平安，屡次申请会在服务器端创立多个资源，不能用于金钱相干的操作）
OPTIONS &＃8211; 用于获取资源上反对的操作。

3. Restful URI设计

1.应用_或-来让URI可读性更好，防止应用空格。 http://www.oschina.net/news/3&＃8230;。
2.应用/来示意资源的层级关系。获取ID为1的用户： http://localhost:8080/UserMan&＃8230;
3.应用?用来过滤资源 /git/git/pulls?state=closed
4.应用,或;示意同级资源的关系（当初github应用…）。 /git/git/compare/master…next。
5.URI里边带上版本号： http://api.example.com/1.0/foo
6.返回后果中提供超链接，疏导用户进行下一步操作。如拜访api.github.com/user返回以下后果：
{&＃8220;message&＃8221;: &＃8220;Requires authentication&＃8221;,　&＃8221;documentation_url&＃8221;: &＃8220;https://developer.github.com/v3&＃8221;}
7.资源有文本、图片等多种格局，客户端能够通过Accept头申请一种特定格局的表述，服务端则通过Content-Type通知客户端资源的表述模式。

　 HTTP响应中提供了状态码，能够分为以下几类：

1xx —— 元数据
2xx —— 正确的响应
3xx —— 重定向
4xx —— 客户端谬误
5xx —— 服务端谬误

4. 长处

　　REST简略而直观，把HTTP协定利用到了极限，它甚至用HTTP申请的头信息来指明资源的示意模式，用HTTP的谬误机制来返回拜访资源的谬误。升高开发的复杂性，缩小了开发构建的老本。因为REST强制所有的操作都必须是stateless的，这就没有上下文的束缚，如果做分布式，集群都不须要思考上下文和会话放弃的问题，极大地提高零碎的可伸缩性。

5. 毛病

　　REST只实用于简略的CRUD业务操作，而无奈解决简单的业务流动，比方校验用户等级，转账，事务处理。此外REST的安全性也绝对较低。

6. 利用

　　JAX-RS（Java API for RESTful Web Services）是一个Java 编程语言的利用程序接口，反对REST架构格调的Web服务。JAX-RS应用了Java SE5引入的Java注解来简化Web服务的客户端和服务端的开发和部署。JAX-RS注解如下：

@Path，标注资源类或者办法的相对路径
@GET，@PUT，@POST，@DELETE，标注办法是HTTP申请的类型。
@Produces，标注返回的MIME媒体类型
@Consumes，标注可承受申请的MIME媒体类型
@PathParam，@QueryParam，@HeaderParam，@COOKIEParam，@MatrixParam，@FormParam　别离标注办法的参数来自于HTTP申请的不同地位，例如@PathParam来自于URL的门路，@QueryParam来自于URL的查问参数，@HeaderParam来自于HTTP申请的头信息，@COOKIEParam来自于COOKIE。
　　基于JAX-RS实现的框架有Jersey，RESTEasy等。这两个框架创立的利用能够很不便地部署到Servlet 容器中，比方Tomcat，JBoss等。值得一提的是RESTEasy是由JBoss公司开发的，所以将用RESTEasy框架实现的利用部署到JBoss服务器上，能够实现很多额定的性能。

四、PRC
　　RPC(近程过程调用)

简略的说RPC就是从一台机器（客户端）上通过参数传递的形式调用另一台机器（服务器）上的一个函数或办法（能够统称为服务）并失去返回的后果。
RPC 会暗藏底层的通信细节（不须要间接解决Socket通信或Http通信）
RPC 是一个申请响应模型。客户端发动申请，服务器返回响应（相似于Http的工作形式）
RPC 在应用模式上像调用本地函数（或办法）一样去调用近程的函数（或办法）。
近程过程调用倒退历程

ONC RPC （凋谢网络计算的近程过程调用），OSF RPC（凋谢软件基金会的近程过程调用）
CORBA（Common Object Request Broker Architecture公共对象申请代理体系结构）
DCOM（分布式组件对象模型），COM+
Java RMI
.NET Remoting
XML-RPC，SOAP，Web Service
PHPRPC，Hessian，JSON-RPC
Microsoft WCF，WebAPI
ZeroC Ice，Thrift，GRPC
Hprose

　　REST次要是基于HTTP之上建设的一种接口标准，外围是资源。SOAP是一种协定，以xml格局传输。RPC是近程办法调用大多是基于TCP之上。如果创立的分布式服务要求较好的安全性，对于传输等底层实现要求较强的可定制性，能够思考SOAP；如果要求设计实现简略，一般来说安全性要求不高能够思考REST。这只是个别状况，但偏于面向资源的服务应用REST有人造的劣势。