关于restful:RESTful和SOAP的区别

48次阅读

共计 9668 个字符，预计需要花费 25 分钟才能阅读完成。

一、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>
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 服务的地位（通常位于公司的企业内部网中）。

  1. 利用场合

    a. 逾越防火墙通信

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

b. 应用程序集成

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

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

  1. 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 提供了一种规范的办法，使得运行在不同的操作系统并应用不同的技术和编程语言的应用程序能够相互进行通信。

1. 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…
申明 SOAP 编码和数据类型的命名空间：http://www.w3.org/2001/12/soa…
语法规定：SOAP 音讯必须应用 XML 编码、SOAP Envelope 和 Encoding 命名空间，且 SOAP 不能蕴含 DTD 援用和 XML 解决指令

  1. 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>

  1. 长处

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

  1. 毛病

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。

1. REST 设计概念和准则

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

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

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

  1. Restful URI 设计

1. 应用_或 - 来让 URI 可读性更好，防止应用空格。http://www.oschina.net/news/3…。
2. 应用 / 来示意资源的层级关系。获取 ID 为 1 的用户：http://localhost:8080/UserMan…
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 —— 服务端谬误

  1. 长处

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

  1. 毛病

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

  1. 利用

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 有人造的劣势。

正文完
restful
发表至： restful
2022-04-23
 0
关于restful:RestfulSOAPRPCSOA微服务之间的区别
关于restful:独立产品灵感周刊-DecoHack-035-YouTube-设计改版了
关于restful:搭建-Restful-Web-服务
关于restful:restful风格