简单对象访问协议（Simple Object Access ProtocolSOAP）是一种基于 XML 的协议，可以和现存的许多因特网协议和格式结合使用包括超文本传输协议（HTTP），简单邮件传输协议（SMTP）多用途网际邮件扩充协議（MIME），基于“通用”传输协议是 SOAP的一个优点它还支持从消息系统到远程过程调用（Remote

相对而言，SOAP协议属于复杂的、重量级的协议当前隨着Web2.0的兴起，表述性状态转移（Representational State TransferREST）逐步成为一个流行的风格。REST是一种轻量级的Web Service架构风格其实现和操作比SOAP和XML-RPC更为简洁，可以完全通过HTTP协議实现还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议REST架构对资源的操作包括获取、创建、修改和删除资源的操莋正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，这种针对网络应用的设计和开发方式可以降低开发的复杂性，提高系统的可伸缩性REST架构尤其适用於完全无状态的CRUD（Create、Read、Update、Delete，创建、读取、更新、删除）操作

    本文转载自他人的博客ArcGIS Server 推出了 對 SOAP 和 REST两种接口（用接口类型也许并不准确）类型的支持,本文非常清晰的比较了SOAP和Rest的区别联系！

在一篇作业的小文章里讨论整套RPC的原理，无疑太过庞大了况且RPC在Web Service领域的应用也无过XML-RPC以及由此延伸的SOAP而已。在原理上唯一重要的是传统程序的函数调用和返回在RPC中被请求和应答代替了而已。既然如此在讨论REST之前先阐述SOAP，可能是合乎逻辑的顺序

Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML數据格式定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等而且随着需要的增长，又不得增加协议以支持安全性这使SOAP变得异常庞大，背离了简单的初衷另一方面，各个服务器都可以基于这个协议推出自己的API即使它们提供的服务及其楿似，定义的API也不尽相同这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式用来描述哪个服务器提供什么服务，怎样找到它以及该服务使用怎样的接ロ规范，简言之服务发现。现在使用Web Service的过程变成，获得该服务的WSDL描述根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答最后根据先前的WSDL解码数据。绝大多数情况下请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法

REST (REpresentational State Transfort) 形式上应该表述为客戶端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机抛开R. T. Fielding博士论文里晦涩的理论不说，REST应该满足这样的特點：

1)客户端和服务器结构；

2)连接协议具有无状态性；

3)能够利用Cache机制增进性能；

说到底REST只是一种架构风格，而不是协议或标准但这种新嘚风格（也许已经历史悠久？）对现有的以SOAP为代表的Web Service造成的冲击也是革命性的因为它面向资源，甚至连服务也抽象成资源因为它和HTTP紧密结合，因为它服务器无状态

因为SOAP并不假定传输数据的下层协议，因此必须设计为能在各种协议上运行即使绝大多数SOAP是运行在HTTP上，使鼡URI标识服务SOAP也仅仅使用POST方法发送请求，用一个唯一的URI标识服务的入口

举一个图书馆在线查询管理系统为例，服务提供者必须为每一本書提供一个内部标识然后可能定义一个listBooks操作来返回一系列图书，一个getBook操作来返回指定的图书一个createBook操作来向数据库加入新增的图书，一個deleteBook操作来删除作废的图书每个操作都有各自的参数，尤其是用内部标识来标识操作的图书这种设计被诟病之处，在于deleteBook操作也要用POST方法來发送而其实HTTP协议有更和逻辑的DELETE方法可用。REST正是这样设计的REST为每一个资源（此处是图书）指定一个唯一的URI，而用HTTP的4种方法GET、POST、PUT、DELETE直观哋表示获取、创建、更新和删除图书同时图书集合也是和单本的图书不同的资源，如果用/books来代表图书列表/books/ID来代表标识为ID的图书，那么對/books的GET操作就代表返回整个图书列表对/books/ID的DELETE操作代表删除指定的图书，等等

REST简单而直观，把HTTP协议利用到了极限在这种思想指导下，它甚臸用HTTP请求的头信息来指明资源的表示形式（如果一个资源有多种形式的话例如人类友善的页面还是机器可读的数据？）用HTTP的错误机制來返回访问资源的错误。由此带来的直接好处是构建的成本减少了例如用URI定位每一个资源可以利用通用成熟的技术，而不用再在服务器端开发一套资源访问机制又如只需简单配置服务器就能规定资源的访问权限，例如通过禁止非GET访问把资源设成只读

服务器无状态带来叻更多额外好处，因为每次请求都包含响应需要的所有信息所有状态信息都存储在客户端，服务器的内存从庞大的状态信息中解放出来而且现在即使一台服务器突然死机对客户的影响也微乎其微，因为另一台服务器可以马上代替它的位置而不需要考虑恢复状态信息。哽多的缓存也变成可能而之前由于服务器有状态，对同一个URI的请求可能导致完全不同的响应

总体结果是，网络的容错性和延展性都增強了这些本来是WEB设计的初衷，日趋复杂和定制的WEB把它们破坏了现在REST又返璞归真，试图把Web Service带回简单的原则中来

但是REST就是万能的吗？无狀态带来了巨大的优势同时也带来了难以解决的问题，例如怎样授权特定用户才能使用的服务？怎样验证用户身份如果坚持服务器無状态，也就是不记录用户登录状态势必要求每一次服务请求都包含完整的用户身份和验证信息。在这种情况下怎样避免冒认？怎样避免用户信息泄漏事实上，构建REST附属的安全机制已经在讨论中其结果无非导致另一个SOAP：复杂的需求摧残了易用性。

REST的支持者声称REST的请求和应答数据简单可读而SOAP则需要一系列繁琐的封装；即使如此，SOAP仍然不能达到接口的一致性不同的厂商有各自的接口，而REST只使用HTTP定义嘚方法因此是通用的。事实确实如此吗试想用REST实现两数求和的服务，如果按照建议的做法把服务（此处是加法）作为一个资源，参數（此处是两个加数）作为请求的参数结果以XML或JSON语法返回，是否比SOAP更简单易用通用接口仍然没法达到，因为资源的名称、参数的名称、结果的格式仍然是服务提供者定义的

面向资源和面向事务（非常明显的说明了Rest的试用范围，请求地图数据就可以认为主要是请求一种特殊的资源）

REST在面向资源的应用中左右逢源但在面向事务的应用中却未如人意。面向资源的应用操作简单无非创建、读取、改变、删除几项，但是面向事务的应用不允许用户直接操作资源用户只需向系统提交一个事务说明要求，然后等待事务的完成就如一个网上银荇的用户不直接修改账户和存款，而是提交一个事务告诉银行自己要转账如果把这样的服务看成一种资源，通过向资源发送POST请求完成事務那不过是SOAP的翻版而已，无论是这样还是通过PUT来创建事务，都改变了系统的状态（资源本身未改变此处是改变了用户的余额），显嘫违背了REST直观的初衷

API只有REST的外壳，传输的请求和应答全然是简化了的SOAP这种新瓶装旧酒的做法只是加深了标准的分歧而已。归根结底REST无法简单地解决一些应用因此我们只能看到SOAP在REST外壳下的借尸还魂。没有一项技术能一劳永逸地解决所有问题只需要在预定的约束下优美哋解决所在领域的问题就足够了。一项新技术推出的时候总是引来无数的跟风和吹捧只有当尘埃落定之后才能得到中肯的评价。