由SOAP说开去 - - 谈谈WebServices、RMI、RPC、SOA、REST、XML、JSON

引子：

关于SOAP其实我一直模模糊糊不太理解，这种模模糊糊的感受表述起来是这样：

1. 在使用web服务时（功能接口），原本我就能够经过安卓中固有的http类（使用http协议），来发送http请求，而且解析返回的数据（通常是xml或者json），获得我要的结果
2. 为何还非得画蛇添足使用soap呢，并且soap本身的介绍也说，它其实没有发明技术，它其实就是http+xml
   1. 在安卓中使用soap的方法是：（下载第三方类库），装配一个soap请求体，使用soap包装过的http类，经过http把请求体发送出去，而后解析返回的soap数据，取出里边的xml数据，获得我要的结果
3. 因此说人家好好的http，你无缘无故在头尾包装一个soap（有点像加一个没有做用的信封，由于HTTP原本就自带信封），这不就是没事收保护费吗，不嫌烦么。（但其实我分析到这发现只是收了一个保护费，我表示还算能够接受吧，毕竟你们都交了）

因而我详细查阅了网上的资料，结合本身的理解，概括整理以下，引用部分过于零散，就未标示，还请谅解

---

 

要好好谈SOAP，就必须从其源头开始，它的源头就是WebServices（Web服务）

 

1.Web服务

最先的软件都是本地软件，只运行在本地电脑上，直到网络技术诞生它也只是利用网络传送资料，这以后网络技术独自发展网页WEB本身发展了好多年，直到你们发现网络技术不仅是用来看看网页，还能够把网络技术更深地应用进本地软件中，深刻地跟本地软件的功能结合，拓展本地软件的功能，Web服务的概念就是在这种环境下兴起的。

 

Web服务 简单地说,，就是服务器如何向客户端提供服务，现有的实现方式能够分为三类：

1. SOA 面向服务的架构【面向消息】
2. RPC  远程过程调用的架构（remote procedure call）【面向方法】
3. REST 表征状态转移的架构（Representational state transfer）【面向资源】

 

1.1.其余相关概念

RMI

1. 使用java的程序员，对于RMI（RemoteMethod Invoke，远程方法调用）必定不陌生，在java中，为了在分布式应用开发时，可以方便调用远程对象，java提供了RMI的API。在 RMI 中,远程对象按照好象它是本地行事，客户机应用程序会直接调用远程对象存根上的方法，所以，调用起来就如本地对象同样方便。RMI中封装了对象和请求的网 络传送，使得异地的对象服务直接可用。
2. 但RMI的使用必须是在可以识别java代码的环境下使用，即必须有JVM的支持。所以，他只适合在java程序间的对象通讯。若是不在 Java 环境下工做,或者须要与非 Java 环境通讯，那么SOAP、RPC、CORAR等都是能够的。.
3. RPC（Remote Method Invocation，远端过程调用） 与RMI的区别很明显，相比于RMI直接获取远端方法的签名，进行调用的方式，RPC使用的是C/S方式，发送请求到服务器，等待服务器返回结果。
4. 通讯方式：远程对象按照好象它是本地行事.客户机应用程序直接调用远 程对象存根上的方法
5. 优势：远程对象按照好象它是本地行事，编译期能够检查错误
6. 缺点：只能基于java语言。异常信息容易丢失。客户机与服务器紧耦合。

 

2.SOA

SOA 是前几年炒的很火的一个词, 不亚于当前的 Cloud Computing , 若是说 RPC 是基于方法调用(method),那么 SOA 则是基于 消息, 基于方法调用一般会与特定的程序语言 耦合起来,然后者则与具体的实现语言无关, 因此在必定程度上获得大公司的支持

 

 

3.RPC

3.1总览：

1. RPC 即远程过程调用, 很简单的概念：像调用本地服务(方法)同样调用服务器的服务(方法).
2. 通常的过程是：向服务器发送一个过程调用的方法及其参数，获得服务器返回的方法执行的结果
3. 通讯方式：通常直接用底层的TCP，这样更加快速，这是相比REST只能用HTTP的优点，但它也可用HTTP

3.2.实现方式：

1. XML-RPC
   1. XML－RPC是一个用XML消息执行RPC的简单协议，服务请求使用XML来编码，并经过HTTP　POST发送，XML响应被嵌入HTTP响应主体。
   2. 在 Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议。XML- RPC中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。（相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源）
2. JSON-RPC
   1. JSON-RPC是基于JSON格式的消息交换，JSON比XML更加轻巧，而且很是容易在页面JS中使用，其余特色与XML-RPC相似
   2. XML-RPC , JSON-RPC的通讯方式相同， 所不一样的只是传输数据的格式，JSON格式更加易用
3. SOAP协议
   1. XML- RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，因而就在使用HTTP的XML-RPC的基础上发展出了更增强大的 SOAP协议，虽然其最初的定义是简单对象访问协议。以后，你们逐渐意识到SOAP其实并不简单，并且也不须要必须使用面向对象语言，因此，如今人们只是沿用SOAP这个名称而已，它常常被用于一些比较复杂的系统之上
   2. SOAP是在计算机之间交换信息的基于XML的协议，主要侧重于经过HTTP传输RPC。它利用了XML的命名空间和XML模式(XML Schema)，比XML-RPC更具适用性，可以支持更多的类型及数据结构。
   3. 简单的说，SOAP定义了如何将一个对象编码成一种格式并经过一种协议传送到另外一个地方并还原的规范。
   4. 固然不少东西都是现成的，对象编码后的格式是XML，传输的应用层协议是HTTP。 HTTP也并无定义如何在网络上进行通讯，其所使用的是TCP协议，TCP也没有定义在路由之间如何传输包，那是IP协议。
   5. 但SOAP也不是什么新东西都没有，譬如对象如何序列化成为XML格式，远程过程调用（RPC）如何实现等，都是SOAP协议的一部分。
   6. XML- RPC只有简单的数据类型集，取而代之，SOAP是经过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也可以利用XML 命名空间，这是XML-RPC所不须要的。如此一来，SOAP消息的开头部分就能够是任何类型的XML命名空间声明，其代价是在系统之间增长了更多的复杂 性和不兼容性。
   7. 最 初，SOAP是做为XML-RPC的扩展而发展起来的，它主要强调的是，经过从WSDL文件中所得到的方法和变量名来进行远程过程调用。如今，经过不断 进步，人们发现了更多的使用SOAP的方式，而不只仅是采用“文件”方式（只是使用一个SOAP信封来传送XML格式化文件）。不管如何，要掌握 SOAP，了解WSDL所扮演的角色是最根本的，看后边的WSDL
   8. SOAP与XML－RPC对比
      1. XML－RPC是启动Web服务最容易的方法，在不少方面比SOAP更简单易用，但不一样于SOAP的是，XML－RPC没有相应的服务描述语法，这妨碍了XML－RPC服务的自动调用
      2. SOAP 有明显的优越性：它很是适合异步通讯和针对松耦合的客户机和服务器。但这种好处会招致一些不利结果。必须作大量的运行时检查，并且开发人员丧失了许多能够确保方法和参数是正确的编译时便利。
      3. 能够认为SOAP是XML-RPC的高级版本，两者基于相同的原理：利用HTTP + XML封装进行RPC调用
   9. 安全与SOAP
      1. 若是企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通讯作出了改善，以便可以处理如下几个问题：
         1. 消息机密性——因为拦截HTTP消息的方式很是多，所以，在请求和响应过程当中，必须可以对全部重要信息加密。很幸运，如今的加密技术很是先进，咱们可以对消息内容进行加密，以保证消息不被修改。
         2. 客户和服务身份——必须可以核实SOAP请求来源的身份。

 

3.3.其余相关概念

yar

yar是PRC的一个框架，相似webservice的，能够远程调用方法，返回的数据不仅仅是字符串，能够是数组等类型。

比方说，当你的项目很是庞大的时候，有些公用的模块就须要对外提供接口。

一、能够用curl方式调用，接口返回xml格式、或者json格式的字符串，调用方本身去解析。

二、能够用使用yar写的方法，直接返回结果，就跟调用代码自己的方法同样，能够返回字符串、数组等格式。

 

Web服务描述语言-WSDL

WSDL(Web Services Description Language)是描述web服务的，是描述怎样访问web服务的。WSDL是用来描述SOAP的，换句话说，WSDL 文件告诉你调用 SOAP 所须要知道的一切。WSDL也是一段xml。如今各个语言对wsdl的支持都很成熟，能够根据同一份wsdl文件生成本身语言的客户端。

为了建立一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便可以构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供如下几个方面的内容：

1. 用于访问服务的地址信息
2. 用于传送信息的传输协议(例如，通道数)
3. 用于全部可以使用功能的名称和接口使用方法
4. 在全部的请求和响应中所使用的数据类型

2001 年3月，W3C推出了WSDL 1.1版本用于讨论，这并非最终肯定的规范。W3C Web服务描述工做组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL一般是用于特定的SOAP服务，可是，从理论说，它是彻底能够 用于特定的REST风格的GET或者POST操做的。

可以根据服务的WSDL描述来自动建立客户端和服务器端代码，支持这一功能的开发环境目前使用得很普遍，以便可以适用于Web服务器和Web服务客户端的 不一样程序设计语言。若是你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许可以使你的开发效率更 高，可是离优化倒是愈来愈远。

 

SOAP数据包结构解析

SOAP的消息被称为一个SOAP Envelope，包括SOAP Header和SOAP Body。其中，SOAP Header能够方便的插入各类其它消息来扩充Web Service的功能，好比Security（采用证书访问Web Service），SOAP Body则是具体的消息正文，也就是Marshall后的信息。

SOAP调用的时候，也就是向一个URL（好比 http://api.google.com/search/beta2 ）发送HTTP Post报文（根据SOAP规范，HTTP Get报文也可被支持），调用方法的名字在HTTP Request Header SOAP-Action中给出，接下来就是SOAP Envelope了。服务端接到请求，执行计算，将返回结果Marshall成XML，用HTTP返回给客户端。

 

 

4.REST

4.1.概念：

1. REST并非一种新兴的技术语言，也不是什么新的技术框架，非协议也非规范 。准确来讲说REST只是一种概念、风格或者约束，是一种针对网络应用的开发方式， 是回归HTTP自己的建议，能够下降开发的复杂性，提升系统的可伸缩性。
2. REST是由Roy Thomas Fieding在他的博士论文《架构风格与基于网络的软件架构设计》中提出的一种架构思想。Roy Fielding是Apache基金会的合做创做者，同时也是HTTP、URI等Web基础协议的主要设计者。从Roy Fielding的背景，我想你们就应该能了解到REST与Web之间的关系了吧。的确，在REST中咱们关注技术实际上也只是URI、HTTP、Hypertext（超文本）而已。
3. REST是中文翻译为表征状态转移（英文：Representational State Transfer）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。从字面意思来讲，“表述”是很难理解是什么东西的？从论文上咱们能够看到表述，通常指HTML文档（包括json，xml等），jpeg等图片资源。
4. REST 采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将全部 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI肯定，而客户端的应用经过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就比如数据库中最基本的增删改查，而互联网上的各类资源就比如数据库中的记录（可能这么比喻不是很好），对于各类资源的操做最后老是能抽象成为这四种基本操做，在定义了定位资源的规则之后，对于资源的操做经过标准的Http协议就能够实现，开发者也会受益于这种轻量级的协议。
5. 谈到REST你们的第一印象就是经过http协议的GET,POST,DELETE,PUT方法实现对url资源的CRUD（建立、读取、更新和删除）操做。这种形式的REST只是CRUD（增删改查），从这个层面上，好像REST只是和RPC一个层面的东西，没有什么了不得，其实这些都是对REST误读。也误导你们实现REST时，特种注重GET,POST,PUT,DELETE方法的处理，包括一些所谓的REST框架，好比JBoss RESTEasy，Restlet Tomcat。究其缘由是， REST提供了一组架构约束，看成为一个总体来应用时，强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减小交互延迟、加强安全性、封装遗留系统的中间组件。其实从整个REST推导过程当中能够了解到，REST没有说起HTTP协议的任何方法，只是后期你们从REST的统一接口中扩展出这些操做概念。

 

4.1.推导REST

先从理论层次上咱们看一下REST是怎么推导来的（参考论文第五章）

         Web架构背后的设计基本原理，可以被描述为由一组应用于架构中元素之上的约束组成的架构风格。当将每一个约束添加到进化中的风格时，会产生一些影响。经过检查这些影响，咱们就可以识别出Web的约束所致使的属性。而后就可以应用额外的约束来造成一种新的架构风格，这种风格可以更好地反映出现代Web架构所期待的属性。经过简述REST做为架构风格的推导过程，后面各节将会详细描述组成REST风格的各类特定约束

     0.   从“空”风格开始。从架构的观点来看，空风格描述了一个组件之间没有明显边界的系统，这就是咱们描述REST的起点。

1. 客户-服务器。客户-服务器约束背后的原则是分离关注点。经过分离用户接口和数据存储这两个关注点，咱们改善了用户接口跨多个平台的可移植性；同时经过简化服务器组件，改善了系统的可伸缩性。
2. 无状态。这个约束致使了可见性、可靠性和可伸缩性三个架构属性，可是无状态并非没有缺点的，无状态增长了在一系列请求中发送的重复数据（每次交互的开销），可能会下降网络性，正由于这个缺点，因此在REST风格中增长了缓存的考虑。
3.  缓存，添加缓存约束的好处在于，它们有可能部分或所有消除一些交互，从而经过减小一系列交互的平均延迟时间，来提升效率、可伸缩性和用户可觉察的性能。可是缓存仍是有缺点的，若是缓存中陈旧的数据与将请求直接发送到服务器获得的数据差异很大，那么缓存会下降可靠性。注意这里的缓存并非指MC，redis之类的缓存，而是在网络代理中，好比proxy服务器上的缓存机制。
4. 统一接口。使REST架构风格区别于其余基于网络的架构风格的核心特征是，它强调组件之间要有一个统一的接口，为了得到统一的接口，须要有多个架构约束来指导组件的行为。REST由四个接口约束来定义：资源的识别（identification ofresources）、经过表述对资源执行的操做、自描述的消息（self-descriptive messages）、以及做为应用状态引擎的超媒体相关因素REST和其余概念关系。统一接口的虽然晦涩，可是它是REST风格核心特征，也是前面咱们讨论经过CURD方式操做资源的一种表现，也是咱们最容易接触感觉到的一层，后面淘宝，微博，微信开放平台的开放接口，其实就是咱们接触这个平台的统一接口，评价一个开发平台是否REST的标准，也在于这个平台的设计者对统一接口的理解。
5. 分层系统，分红系统风格经过限制组件的行为（即，每一个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。经过将组件对系统的知识限制在单一层内，为整个系统的复杂性设置了边界，而且提升了底层独立性。分层系统增长了数据处理的开销和延迟，所以下降了用户可觉察的性能对于一个支持缓存约束的基于网络的系统来讲，能够经过在中间层使用共享缓存所得到的好处来弥补这一缺点。正由于REST风格有这样的缺点，才会特地强调缓存的做用。
6. 按需代码，经过下载并执行applet形式或脚本形式的代码，REST容许对客户端的功能进行扩展，看似简单的一种风格设计，其实对B/S贡献最大的就是这个特性，如今ajax的底层其实就是按需代码机制。

 

4.2.REST风格/约束：

Fielding 在他的论文中提出了一个RESTful应用应该具有的几点约束。

1. 每一个资源都应该有一个惟一的标识
2. 使用标准的方法来更改资源的状态
3. Request和Response的自描述
4. 资源多重表述
5. 无状态的服务

Fielding 认为，只有具有了上面的约束的应用才能算是REST应用，其实如今许多所谓的REST应用或服务，其实并不能算是真正的REST应用，目前不少所谓的REST应用，其实只是RPC而已。出现这样的状况很正常，由于RPC更符合通常程序员的思惟。

以后这几个约束被表述为：

1. Client–server C/S结构 (这是Internet服务的一个基本特征)
2. 无状态性
3. 可以利用Cache机制增进性能 (想起了浏览器?)
4. 分层系统 (想起了无数的架构?)
5. 统一的接口规范分层交互
6. 随需代码 - Javascript （可选，实际上是一种扩展性的要求)

 

看了这几个特征后,你想起了什么? 你可能会破口而出：HTTP

HTTP是WWW的最核心的协议, 它将简单的分布于世界各个角落的资源都统一块儿来, 统一的地址, 简单的方法, 和必定数量的表达方式.(你可能对这三点描述很模糊,请go ahead).

REST 的三个要素就是是 惟一的资源标识, 简单的方法 (此处的方法是个抽象的概念), 必定的表达方式.

REST 是以 资源 为中心, 名词即资源的地址, 动词即施加于名词上的一些有限操做, 表达是对各类资源形态的抽象.

以HTTP为例，名词即为URI(统一资源标识), 动词包括POST, GET, PUT, DELETE等(还有其它不经常使用的2个,因此 整个动词集合是有限的), 资源的形态(如text, html, image, pdf等)

 

根据以上的描述，咱们其实发现HTTP是一种典型的REST风格，这也难怪，在1994年提出REST风格时，REST被称做“HTTP对象模型”，可是那个名称经常引发误解，令人们误觉得它是一个HTTP服务器的实现模型。这个名称“表述性状态转移”是有意唤起人们对于一个良好设计的Web应用如何运转的印象。反过来看HTTP就是REST的具体实现。在一个REST风格中，咱们可以感觉到的就是统一接口的数据，这些数据包括因此，当咱们开发一个web服务时，好比一个网站，因为使用了HTTP(HTTPS)协议，其实就是一种REST风格，可是在这个REST风格中咱们着重处理的是两点

       1：URI，即所谓的资源，网站的uri设计

       2：统一接口，即所谓的PUT,GET,POST,DELETE方法

虽然咱们的网站是REST的风格的，可是因为统一接口设计的很差，致使咱们网站在访问请求时，效率低下，以及可扩展性差。在深刻浅出REST中，做者总结了五条关键原

        1：为全部“事物”定义ID

        2：将全部事物连接在一块儿

        3：使用标准方法

        4：资源多重表述

        5：无状态通讯

其中前四条就是对统一接口中的数据元素，第一二条讲的就是uri，第三四条讲的是控制数据。第五条无状态通讯，这个须要特别说明下，无状态通讯是指服务器和客户端通讯是无状态的，假如咱们的系统中使用Session保存客户端状态，这种状况就是非无状态通讯，是一种unREST的方式。可是应用自己是有状态的，好比用户登陆先后，就是应用状态的变化。

 

 

4.3.REST与WEB

Fielding指出，使用且符合表明性状态传输(REST)设计约束的 Web 上部署的组件，能够充分利用 Web 的有用特性，万维网(World Wide Web)才可以达到最佳的工做效果。能够这样理解REST——当一个浏览器获得而且显示构成HTML页面的各个元素时，它正在获取资源的当前状态的表现形式。在Fielding的博士论文中，他列举了REST风格的设计约束，而且解释了为何这些约束可以充分利用Web 的有用特性，使其达到最佳状态，以及这些约束的关键所在。同时，在论文中，他也包含了一些关于REST和某些目前的Web风格之间 “不符合”的讨论，以及这些Web风格是如何致使设计没法利用Web特性的。

Fielding认为，对于使用HTTP承载应用程序协议穿越防火墙，XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。”它们所采用的方式违背了设立防火墙的概念，结果是，防火墙厂商为了保护系统须要侦察出所承载的协议。因为大多数SOAP应用程序使用HTTP都是为了穿越防火墙，所以，你能够发现REST与SOAP之间的冲突是从哪里开始的。Fielding认为，若是你打算使用HTTP的话，就应该与充分利用HTTP自己的含义。

REST风格强调，经过有限的操做或者是“动词”以及一个组件之间的标准接口，也就是HTTP协议提供的借口，来提高客户与服务之间的交互。经过为每个资源分配其本身的URL，来实现灵活性，REST能够调用包含上百个URI的资源类型的客户，其中的关键是REST可以给你无限多的“名词”。REST使用HTTP的动词——简单的良定义操做集:POST, GET, PUT,DELETE进行请求和响应，从而避免了歧义。举个例子，GET只可以简单地返回资源的表现形式，而不可以建立任何其余的内容。

在Web发展的初期，因为人们都在试验经过收集各类不一样来源的元素，从而把Web应用程序融合在一块儿，有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息，用于页面建立者没有计划到的用途。这种“屏幕抓取”的Web类比代表，REST风格的方法是先于那些更加复杂的Web服务而出现的。

 

4.4.规划REST服务

在InfoQ上有一篇很好的文章来介绍如何规划REST服务《如何获取（GET）一杯咖啡——星巴克REST案例分析》，估计你们看完这篇文章，应该对如何规划REST服务会有更深的认识。

当咱们要规划REST服务的时候，其中最关键的概念是“资源”。

资源是什么呢？广义上讲，任何事物只要有用，它就是资源。狭义的讲（在Web环境中），它是一个能够存放、链接在计算机上，能够经过比特流进行操控的实体。一个实体若要成为资源，它必须有一个URI。在这里URI包含了两重含义：1)它是该资源的名称 2)它是该资源的地址。

在规划URI的时候，有几点但愿你们可以注意一下：

1. 一个URI标识一个资源，可是一个资源能够被多个URI标识。
2. 资源也是有层次的，这个层次应该在URI上充分的体现出来。
3. 在规划URI的时候，须要定义一些团队内部确认的关键字或符号，这些关键字或符号是有特殊意义的，不能随便使用。
4. 须要有一个URI定义的文档，以备之后的查询和维护。
5. 能够使用URI Template来描述URI的定义。如何使用URI Template请看看这篇文章。

当咱们定义好资源以后，接下来要作的事情就是定义操做资源的方法以及资源的表述格式了。

使用HTTP提供的基本方法来对资源进行操做，通常的操做定义以下：POST（建立资源）、GET（获取资源）、PUT（修改资源）、DELETE（删除）。它们正好对应了CRUD。

对资源的表述，通常的选择会是XML，可是我更加推荐使用JSON来表述资源。在网络中的传输量小，并且也便于JavaScript解析，同时使用其余语言解析也是很是方便的事情。不过，最关键的仍是占用更少的资源，让一样的资源可以服务于更多的人。

 

 

4.5.一个简单的REST举例

　　假设咱们但愿一个Web服务暴露一部分目录，从这个目录中，用户将可以获得一些描述、图片、安装指令等等。为了获得数字“n1996-01”的描述，用户须要格式化一个GET请求，相似于下面的这个URL： http://company.com/catalog/description/n1996-01

　　在处理这个请求时，“/catalog”将映射到一个服务中，以后，经过该服务对“description/n1996-01”进行解释，从而 定位资源。在建立响应时，服务须要使用内容类型(Content-Type)的头文件来指定返回格式。在这种状况下，假定返回格式是HTML或者XML， 客户端可以使用它来控制页面的布局。若是要获得图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是 图片内容类型(Content-Type)。

 

 

4.6.REST的应用场景：

其实，咱们常常容易犯的一个错误是：当咱们了解了一个新的技术，就会用这个技术来解决全部的问题。有一句谚语是这么来讲的：“在锤子的眼里，全部的东西都是钉子”，其实REST也只是咱们工具箱里面的其中的一个工具而已，但愿不要把它当作咱们惟一的工具。下面，咱们就来聊聊适合使用REST的应用场景和不适合使用REST的应用场景。

在我看来，REST最适合的应用场景是须要对外暴露服务的状况。此时，咱们能够充分利用REST的自描述、无状态、惟一标识等特性来提供清晰、友好的API；此外，目前Jesery、RESTEasy等JAX-RS框架也提供了OAuth的支持，基本上可以保证服务安全。

最不适合的应用场景是对性能要求高的系统内部的服务调用，在这种状况下使用REST的话，那么REST全部的特性都会变成拖累。这个时候，仍是须要选择更底层的通讯协议和方式会更好一些，好比ICE。这样的错误，我曾经犯过，后来经过很长时间的努力才慢慢的将这个错误改过来。

 

4.7.RPC与REST的比较

1. RPC是以动词为中心的，REST是以名词为中心的，此处的动词指的是一些方法，名词是指资源。REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们
   1. 你会发现,以动词为中心,意味着,当你要须要加入新功能时,你必需要添加更多的动词, 这时候服务器端须要实现 相应的动词(方法), 客户端须要知道这个新的动词并进行调用.
   2. 而以名词为中心, 假使我请求的是 hostname/friends/, 不管这个URI对应的服务怎么变化,客户端是无需 关注和更新的,而这种变化对客户端也是透明的.
   3. 一个基于RPC的架构，动词数量是 没有限制的。REST说，咱们使用四个动词——很是熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资 源寻址来处理其可变性
2. 至于其它的区别,如对实现语言的依赖, 耦合性等,这些都是上面提到的这个根本区别所衍生的
3. REST回归HTTP最初的设计；RPC仅仅只是把HTTP做为传输协议来使用。
4. REST是由超文本驱动的；RPC是由方法驱动的。
5. REST强调HTTP通讯的语义可见性，经过消息头和标准的HTTP方法来体现；RPC把语义封装在HTTP消息体中。

如何选择?

根据笔者本身的经验和心得, 建议 可以使用REST就尽可能使用REST, 主要基于下面几个考虑:

1. 扩展性
2. 松耦合(意味着,不用强制要求客户端去更新相应的代码)
3. 客户端实现语言无关
4. 性能
5. 安全性(例如HTTPS)

固然上述的几点也并不是 RPC 都不知足,不过相对而言, REST 更加清晰和简洁, 再辅以 JSON 相应的服务会在性能和稳定性(简单一般意味着robust)方面有很大的提升.

 

整体上，由于REST模式的Web服务与复杂的SOAP和XML-RPC对比来说明显的更加简洁，愈来愈多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST对于资源型服务接口来讲很合适，同时特别适合对于效率要求很高，可是对于安全要求不高的场景。而SOAP的成熟性能够给须要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。因此我以为纯粹说什么设计模式将会占据主导地位没有什么意义，关键仍是看应用场景，正是那句老话：适合的才是最好的

同时很重要一点就是不要扭曲了REST如今不少网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不三不四，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

 

4.8.soap与REST比较：

1. REST依赖一套简单的“动词”，把全部的复杂性都转移到了指定资源的“名词”中。与此不一样，SOAP却有一套至关复杂的XML格式化命令和数据传输选项。
2. 很是重要一点是，REST是须要请求HTTP的，与其相比，SOAP更具优点，SOAP消息能够由全部可以处理Unicode文本的传输方式来传 送，很惋惜，这一点一般不被人们所承认。事实是，因为HTTP穿透防火墙的便捷性，以及开发商们对Web很是熟悉，所以，人们还在继续强调着HTTP传 输。
3. 在 开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此以外，如今，有许多 集成开发环境可以在现有代码的基础上，依据接口方法自动生成SOAP。若是你须要使用WSDL来发布你的服务，或者你须要一些安全功能如消息签名和加密， 那么，SOAP可以确保消息的安全性。另外一方面，若是你但愿使用简单接口来公布一些信息，而不须要繁琐的处理过程，那么，REST也许是最佳选择。
4. 众多从事Web服务的软件设计师们认为SOAP过分复杂，因而，相似eBay和Google的服务都采用了REST风格的约束来暴露其大量数据。
5. 甚至能够有RESTful SOAP。尽管还网上没人提到RESTful SOAP，但我以为这在理论上是没问题的

形成SOAP和REST放在一块儿讨论是由于，网络上不少工程师把REST风格和REST的实现混淆了。REST的概念比较宽泛，自己若是符合1)Client–server, 2)Stateless, 3)Cacheable, 4)Layered system, 和5)Uniform interface这几个主要的限制，就是RESTful的设计。同时呢，因为HTTP是一个很容易知足stateless, cacheable，uniform interface的protocol,因此实际上REST被默认就是用HTTP来实现，不少人耳熟能详HTTP的verb如何对应到resource的CRUD，仿佛也成了REST风格自己的死规定。我认为其实否则，以HTTP中的PUT为例，若是用PUT来实现resource的update,那么就必需要保证idempotent，每次传给server的信息，必须是resource的所有信息，不能做partial update。不难发现，用PUT来实现update，实际上是在REST的constraint上又加上了HTTP的一些限制。若是咱们放弃PUT的constraint，采用POST来实现update，则partial update是能够的。紧接着就由一个问题，既然PUT被POST替代，那么咱们是否能够用POST来代替GET和DELETE呢？笔者认为应该没问题，一个很现实的例子，若是browser不支持DELETE，用POST来work around是很常见的。

okay, 再来看看SOAP，不少在HTTP上实现的SOAP协议就是用POST来实现的 (wikipedia里SOAP的一个sample http://en.wikipedia.org/wiki/SOAP#Example_message)

所以，当咱们使用HTTP POST来实现REST，再加上XML的数据传输格式，其实咱们就是在SOAP上面实现了RESTFul的"风格"(尽管还网上没人提到RESTful SOAP，但我以为这在理论上是没问题的)。

与RESTful SOAP相对的一个例子，不少基于Rails的website（并不是说Rails很差，Rails大行其道使得REST风行，故举例）URL风格是/callSomeMethodWithArgumentA, /callSomeMethodWithArgumentB，很是长，不uniform，不知足REST的限制，这些route都是不RESTFul的，咱们能够称之为non-RESTful HTTP

长话短说，本人认为SOAP协议和REST架构风格是兼容的。虽然，约定俗成，REST的具体实现通常采用HTTP，且充分利用HTTP verb的不一样特性，从而造成了一些约定俗称的范式，但这种实现自己不是REST"风格"的核心。

 

目前，大部分Web开发者彷佛都了解REST——一种采用标准URI进行调用的方案。REST很容易理解，并且只要是支持HTTP/HTTPS的客户端/服务器就支持它。你能够用HTTP GET方法来执行命令。因此，开发者们感觉到的REST的优点是：开发简单、只需依托现有Web基础设施、以及学习成本低。

然而，SOAP做为一种古老的Web服务技术，短时间内还不会退出历史舞台。并且，随着SOAP 1.2的出现，SOAP印象中的一些缺点已获得改进，采纳率和易用程度也都获得提升。另需注意的是，从W3C SOAP 1.2版开始，SOAP这一缩写再也不表明Simple Object Access Protocol（简单对象访问协议），而是仅仅做为协议名称而已。

相对REST而言，SOAP 1.2多出一些开销，不过这些开销也带来了一些好处。首先，SOAP在三个方面离不开XML（Extensible Markup Language，可扩展标记语言）：SOAP信封（envelope）是基于XML的，它定义了消息里有什么以及如何处理它；一套用于数据类型的编码规则；过程调用和响应的规划。SOAP信封由传输协议（HTTP/HTTPS）发出，RPC（Remote Procedure Call，远程过程调用）获得执行，而后一个XML文档随SOAP信封返回。

须要注意的是，基于“通用”传输协议是SOAP的一个优势。REST目前基于HTTP/HTTPS；而SOAP可支持任何传输协议，从HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，简单邮件传送协议），甚至JMS（Java Messaging Service，Java消息传递服务）。不过，因为XML较为冗长且解析费时，所以采用XML也成为一个弊端。

不过，对Web开发者来讲的好消息是，目前上述两种方案都是行之有效的方案。REST和SOAP都能解决许多Web方面的问题与挑战，并且在许多状况下，它们各自都能知足开发者的要求，也就是说可互换使用。

但不少人不知道，这两种技术能够混合搭配使用。REST很好理解，且极易上手；不过因为它缺少标准，所以只被看做是一种架构方法。与之相比，SOAP是一个工业标准，它具有良好定义的协议，以及一套良好确立的规则，在大型和小型系统中均有采用。

所以，REST的适用场合包括：

有限的带宽和资源 别忘了返回的结构能够采用（由开发者定义的）任何格式。另外，因为REST采用标准的GET、PUT、POST和DELETE动词，所以可被任何浏览器所支持。除此之外，REST还能够使用为目前大多数浏览器支持的XMLHttpRequest对象，这为AJAX增色很多。

彻底无状态的操做 对于那些需多步执行的操做，REST并不是最佳选择，采用SOAP更合适。可是，若是你须要无状态的CRUD（Create/Read/Update/Delete，建立/读取/更新/删除）操做，那么应采用REST。

缓存考虑 若要利用无状态操做的特性，使得信息可被缓存，那么REST是很好的选择。

以上已经覆盖不少方案了，那么，为何还要考虑SOAP呢？正如前述，SOAP比较成熟并且是通过良好定义的，具备完整的规范。而REST只不过是一种方法，对开发未做任何规约；所以，假如你遇到如下场合，那么SOAP是最佳选择：

异步处理与调用 若是你的应用须要确保可靠性与安全性，那么请采用SOAP。SOAP 1.2为确保这种操做补充定义了WSRM（WS-Reliable Messaging）等标准。

形式化契约 若提供者/消费者双方必须就交换格式取得一致，那么采用SOAP更合适。SOAP 1.2为这种交互提供了严格的规范。

有状态的操做 若是应用须要上下文信息与对话状态管理，那么应采用SOAP。SOAP 1.2为此补充定义了WS-Security、WS-Transactions和WS-Coordination等标准。相比之下，REST方法要求开发者本身来实现这些框架性工做。

正如你所看到的，REST和SOAP各自有其用武之地。它们在安全性和传输层等方面有着本身的潜在问题，不过它们都能完成任务，并且在许多状况下，它们都丰富了Web的技术手段。所以，就这一论题，其实最好的原则就是灵活性原则；由于至少在现今的Web开发中，不管面对何种问题，Web开发者们总有办法运用好这两种技术中的一种。