RESTful和SOAP的区别
参考：【接口开发】浅谈 SOAP Webserver 与 Restful Webserver 区别
目录
客户端和服务器端的通讯方式：
一、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 的代码。实例如下：
<?xml version="1.0" encoding="UTF-8" ?> <definitions targetNamespace="http://schemas.xmlsoap.org/HelloService" xmlns:tns="http://schemas.xmlsoap.org/HelloService" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding" xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <!-- （参数类型） 数据类型定义，一般使用XML Schema中的类型系统 --> <types> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://schemas.xmlsoap.org/HelloService" attributeFormDefault="qualified" elementFormDefault="qualified" > <xsd:element name="sayHello"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="name" nillable="true" type="xsd:string" /> </xsd:sequence></xsd:complexType></xsd:element> <xsd:element name="sayHelloResponse"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="name" nillable="true" type="xsd:string" /> </xsd:sequence></xsd:complexType></xsd:element> </xsd:schema> </types> <!-- （操作中的参数） 使用Types所定义的类型来定义整个消息的数据结构 --> <message name="sayHelloRequest"> <part name="parameters" element="tns:sayHello" /> </message> <message name="sayHelloResponse"> <part name="parameters" element="tns:sayHelloResponse" /> </message> <!-- （提供的操作） portType描述了一组操作 --> <portType name="HelloServicePortType"> <operation name="sayHello"> <input name="sayHelloRequest" message="tns:sayHelloRequest" /> <output name="sayHelloResponse" message="tns:sayHelloResponse" /> </operation> </portType> <!-- （绑定通信协议）描述如何将portType映射成传输／消息传递协议,binding将portType绑定到特定的协议（例如 SOAP、HTTP或MIME）--> <binding name="HelloServicePortBinding" type="tns:HelloServicePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="sayHello"> <!-- 元素的soapAction属性被转换成HTTP头 --> <soap:operation soapAction="" /> <input name="sayHelloRequest"> <soap:body use="literal" /> </input> <output name="sayHelloResponse"> <soap:body use="literal" /> </output> </operation> </binding> <!-- （有特定操作的服务）service列出某个特定绑定的连接信息。服务可以有一个或多个端口，每个端口都定义一个不同的连接方法（例如HTTP/SMTP等等） --> <service name="HelloService"> <port name="HelloServiceHttpPort" binding="tns:HelloServicePortBinding"> <soap:address location="http://localhost:8080/services/HelloService" /> </port> </service> </definitions>
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做为企业级中间件，不同系统之间的通信只能用称为"桥"的技术(Bridge)来解决，这些"桥"由软件厂商提供给开发者使用，而且不同版本间的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/soap-envelope
声明SOAP 编码和数据类型的命名空间：http://www.w3.org/2001/12/soap-encoding
语法规则：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 <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope> SOAP 响应： HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope>
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 - 提供资源的只读访问。（只读且安全） -- 幂等性：重复执行结果不变，就算在失败以后。安全性：是否改变服务端的状态。
- PUT - 用于创建一个新资源。（幂等不安全，因其幂等性可用于金钱相关的操作）
- DELETE - 用于移除一个资源。（幂等）
- POST - 用于更新现有资源或者创建一个新资源。（不幂等不安全，多次请求会在服务器端创建多个资源，不能用于金钱相关的操作）
- OPTIONS - 用于获取资源上支持的操作。
3. Restful URI设计
1.使用_或-来让URI可读性更好，避免使用空格。 http://www.oschina.net/news/38119/oschina-translate-reward-plan。
2.使用/来表示资源的层级关系。获取ID为1的用户： http://localhost:8080/UserManagement/rest/UserService/users/1
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返回以下结果：
{"message": "Requires authentication", "documentation_url": "https://developer.github.com/v3"}
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注解如下：
基于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有天然的优势。
