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

于是我详细查阅了网上的资料，结合自己的理解，归纳整理如下，引用部分过于零散，就未标示，还请谅解

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

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语言。异常信息容易丢失。客户机与服务器紧耦合。

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

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请求来源的身份。

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的统一接口中扩展出这些操作概念。

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的底层其实就是按需代码机制。

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

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

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

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消息体中。

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

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，但我觉得这在理论上是没问题的