SOAP及Rest的挪用区别参照如下：
REST似乎在一夜间兴起了，这可能引起一些争议，阻挡者可以说REST是WEB诞生之始甚而是HTTP呈现之日就相伴而生的原则。但是毋庸置疑的事实是，在Google和Yahoo等网络巨头颁布的不异成果的Web Service API中，REST无疑受到更多的青睐，因此是不是可以这样说：RPC在一夜之间衰落了？ 在一篇功课的小文章里讨论整套RPC的道理，无疑太过复杂了，况且RPC在Web Service范围的应用也无过XML-RPC以及由此延伸的SOAP而已。在道理上独一重要的，是传统措施的函数挪用和返回在RPC中被请求和应答取代了而已。既然如此，在讨论REST之前先论述SOAP，，可能是合乎逻辑的挨次。 什么是SOAP? SOAP (Simple Object Access Protocol) 顾名思义，是一个严格界说的信息交换协议，用于在Web Service中把长途挪用和返回封装成机器可读的格局化数据。事实上SOAP数据使用XML数据格局，界说了一整套庞大的标签，以描述挪用的长途过程、参数、返回值和堕落信息等等。而且跟着需要的增长，又不得增加协议以撑持安适性，这使SOAP变得异常复杂，背离了简单的初衷。另一方面，各个处事器都可以基于这个协议推出本身的API，即使它们供给的处事及其相似，界说的API也不尽不异，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格局，用来描述哪个处事器供给什么处事，怎样找到它，以及该处事使用怎样的接口规范，简言之，处事发明。此刻，使用Web Service的过程酿成，获得该处事的WSDL描述，按照WSDL结构一条格局化的SOAP请求发送给处事器，然后接收一条同样SOAP格局的应答，最后按照先前的WSDL解码数据。绝大大都情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST要领。 什么是REST？ REST (REpresentational State Transfort) 形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以当作一台虚拟的状态机。抛开R. T. Fielding博士论文里晦涩的理论不说，REST应该满足这样的特点：1)客户端和处事器布局；2)连接协议具有无状态性；3)能够操作Cache机制增进性能；4)条理化的系统；5)按需代码。说到底，REST只是一种架构气势派头，而不是协议或标准。但这种新的气势派头（也许已经历史悠久？）对现有的以SOAP为代表的Web Service造成的攻击也是革命性的，因为它面向资源，甚至连处事也抽象成资源，因为它和HTTP紧密结合，因为它处事器无状态。 REST与SOAP的区别 因为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的长处 REST简单而直不雅观，把HTTP协议操作到了极限，在这种思想指导下，它甚至用HTTP请求的头信息来指明资源的暗示形式（如果一个资源有多种形式的话，例如人类友善的页面还是机器可读的数据？），用HTTP的错误机制来返回访谒资源的错误。由此带来的直接好处是构建的本钱减少了，例如用URI定位每一个资源可以操作通用成熟的技术，而不用再在处事器端开发一套资源访谒机制。又如只需简单配置处事器就能规定资源的访谒权限，例如通过禁止非GET访谒把资源设成只读。 处事器无状态带来了更多特别好处，因为每次请求都包罗响应需要的所有信息，所有状态信息都存储在客户端，处事器的内存从复杂的状态信息中解放出来。而且此刻即使一台处事器俄然死机对客户的影响也微乎其微，因为另一台处事器可以顿时取代它的位置，而不需要考虑恢复状态信息。更多的缓存也酿成可能，而之前由于处事器有状态，对同一个URI的请求可能导致完全差此外响应。总体功效是，网络的容错性和延展性都增强了，这些原来是WEB设计的初衷，日趋庞大和定制的WEB把它们粉碎了，此刻REST又返璞归真，试图把Web Service带回简单的原则中来。 REST是万能的吗？ 但是REST就是万能的吗？无状态带来了巨大的优势，同时也带来了难以解决的问题，例如，怎样授权特定用户才华使用的处事？怎样验证用户身份？如果对峙处事器无状态，也就是不记录用户登录状态，势须要求每一次处事请求都包罗完整的用户身份和验证信息。在这种情况下，怎样制止冒认？怎样制止用户信息泄漏？事实上，构建REST从属的安适机制已经在讨论中，其功效无非导致另一个SOAP：庞大的需求摧残了易用性。 REST的撑持者声称REST的请求和应答数据简单可读，而SOAP则需要一系列繁琐的封装；即使如此，SOAP仍然不能到达接口的一致性，差此外厂商有各自的接口，而REST只使用HTTP界说的要领，因此是通用的。事实确实如此吗？试想用REST实现两数求和的处事，如果凭据建议的做法，把处事（此处是加法）作为一个资源，参数（此处是两个加数）作为请求的参数，功效以XML或JSON语法返回，是否比SOAP更简单易用？通用接口仍然没法到达，因为资源的名称、参数的名称、功效的格局仍然是处事供给者界说的。为了解决这个问题，提出了WASL(Web Application Description Language)来描述REST接口。WADL就像是WSDL的REST版，跟着REST被应用到庞大的范围，SOAP的影子无处不在。 面向资源和面向事务 REST在面向资源的应用中摆布逢源，但在面向事务的应用中却未如人意。面向资源的应用操纵简单，无非创建、读取、转变、删除几项，但是面向事务的应用不允许用户直接操纵资源，用户只需向系统提交一个事务说明要求，然后期待事务的完成，就如一个网上银行的用户不直接改削账户和存款，而是提交一个事务报告银行本身要转账。如果把这样的处事当作一种资源，通过向资源发送POST请求完成事务，那不过是SOAP的翻版而已，无论是这样，还是通过PUT来创建事务，都转变了系统的状态（资源自己未转变，此处是转变了用户的余额），显然违背了REST直不雅观的初衷。 事实上，一些Web Service供给者供给的REST API只有REST的外壳，传输的请求和应答全然是简化了的SOAP，这种新瓶装旧酒的做法只是加深了标准的不合而已。归根结底REST无法简单地解决一些应用，因此我们只能看到SOAP在REST外壳下的借尸还魂。没有一项技术能一劳永逸地解决所有问题，只需要在预定的约束下优美地解决地址范围的问题就足够了。一项新技术推出的时候总是引来无数的跟风和吹嘘，只有当尘土落定之后才华得到中肯的评价。
创建处事:15383/WebService1.asmx，如下: