WebService的两种⽅式SOAP和REST，之间的区别与优缺点什么是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 API
优点：
1. 轻量级的解决⽅案，不必向SOAP那样要构建⼀个标准的SOAP XML。
2. 可读性⽐较好：可以把URL的名字取得有实际意义。
调用webservice服务3. 不需要SDK⽀持：直接⼀个Http请求就可以，但是SOAP则可能需要使⽤到⼀些Webservice的类库（例如Apache的Axis）
缺点：
1. 复杂的应⽤中，URL可能⾮常长，⽽且不容易解析。
SOAP API
优点：
1. 定义严格。必须符合SOAP的格式
2. 某些时候使⽤⽐较⽅便
3. 开发⼯具⽀持⽐较多⼀点。
缺点：
1. 需要⽣成WSDL⽂件
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外壳下的借⼫还魂。没有⼀项技术能⼀劳永逸地解决所有问题，只需要在预定的约束下优美地解决所在领域的问题就⾜够了。⼀项新技术推出的时候总是引来⽆
数的跟风和吹捧，只有当尘埃落定之后才能得到中肯的评价。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。