SOAP REST

SOAP是基于RPC原理，是传统程序的函数调用和返回在RPC中被请求和应答代替了而已。

SOAP Simple Object Access Protocol,是一种严格定义的信息交换协议，用于在web service中把远程调用和返回封装成机器可读的格式化数据。SOAP使用XML格式，定义了一整天复杂的标签，以描述调用的远程过程、参数、返回值和出错信息、增加协议以支持安全性等。另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生，Web Service Description Language也遵循XML格式，用来描述那个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用ws的过程变成，获得该服务的WSDDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样的SOAP格式的应答，最后根据先前的WSDL解码数据，绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

REST REpresentational State Transfort 形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。REST应该满足这样的特点：

1. 客户端和服务器结果；

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

3.能够利用cache机制增进性能；

4.层次化的系统；

5.按需代码。

说到底。REST只是一种架构风格，而不是协议或标准，对现有的以SOAP为代表的ws造成冲击，因为它面向资源，甚至来服务器也抽象为资源，因为它和HTTP紧密结合，因为它服务器无状态。

REST和SOAP的区别：

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

REST优点：

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

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

总体结果是，网络的容错性和延展性都增强了。

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

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

事实上，一些ws提供者提供的REST API只有REST的外壳，传输的请求和应答全是简化了的SOAP。

转载自：https://www.cnblogs.com/reynold-lei/p/3724684.html