RESTful和SOAP比较

亦凉 2022-06-07 10:26 242阅读 0赞

1、**RESTful**

一种软件架构风格，设计风格而**不是**标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

REST（英文：**Representational State Transfer**，简称**REST**）描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000年Roy Fielding的博士论文中，他是HTTP规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。

### **原则条件** ###

REST 指的是一组架构[约束条件][Link 1]和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合[云计算][Link 2]之类的环境。客户端可以缓存数据以改进性能。

在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier)得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的HTTP方法，比如GET、PUT、[POST][] 和[DELETE][]。

### **分层系统** ###

另一个重要的 REST原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。

当 REST架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST简化了客户端和服务器的实现。

REST 描述了一个架构样式的互联系统（如Web应用程序）。REST约束条件作为一个整体应用时，将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过HTTP直接传输数据的特性，RESTful Web服务成为基于SOAP服务的一个最有前途的替代方案。用于web服务和动态Web应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。开发人员可以轻松使用Ajax和RESTful Web服务一起创建丰富的界面。

\[摘自百度百科\]

**2、SOAP与RESTful区别**

Web服务有两种实现方式，一是SOAP协议方式，二是REST方式。SOAP是一套完整的实现Web服务的解决方案。这里有必要先简单了解SOAP方式的Web服务，然后对比SOAP方式，我们会发现REST方式欠缺了什么。

SOAP方式的Web服务中的Web服务描述语言（WSDL）和简单对象访问协议（SOAP）一起构成了SOAP方式下的Web服务的结构单元。客户端通过WSDL可以了解Web服务公开了那些可以被执行的方法以及Web服务可以发送或接收的消息格式（解决了公布访问资源方法的问题）。客户端按照SOAP将调用位于远程系统上的服务所需信息序列化为消息（解决了如何调用远程方法的问题）。注意WSDL描述的服务以及SOAP消息都是符合统一标准的，都是机器可读的.

WSDL基于XML格式，用来描述Web服务。WSDL文档可以看成是客户端和服务器之间的一个协约。使用WSDL工具，你可以自动处理这个过程，几乎不用手工编写代码就能够让应用程序整合新的服务。因此WSDL是Web服务体系结构的基础，因为它提供了一个通用语言，用来描述服务和整合这些服务的平台。

SOAP本身提供了与Web服务交换信息的方法。SOAP是序列化调用位于远程系统上的服务所需信息的标准方法，这些信息可以使用一种远程系统能够读懂的格式通过网络发送到远程系统，而不必关心远程系统运行于何种平台或者使用何种语言编写。SOAP以XML格式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。

对照SOAP方式的Web服务，REST中没有用于描述资源（服务）列表，资源元数据的类似于WSDL的东东。所以有人在2009年提出了一个标准WADL去描述REST方式的Web服务，但至今没有被标准化。个人认为使用WSDL/WADL去描述REST方式的Web服务太别扭，这是典型的RPC思路，而REST是一种把服务抽象为资源的架构思想。用描述RPC的WSDL去描述REST方式的Web服务并不合适。我们需要其他策略去代替WSDL实现“公布访问资源方法的问题”。

由于没有类似于SOAP的权威性协议作为规范，因此各个网站的REST实现都自有一套，也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web service，但细节方面有太多没有约束的地方，其统一通用方面远远不及SOAP。

举个例子：假设A组织，B组织都实现了Restful API来通过工号查询人员信息，因为没有统一的规范。

A的API 可能是这样：[http://A/api/person/001][http_A_api_person_001]

B的API 可能是这样：[http://A/api/person/id=001][http_A_api_person_id_001]

第三方客户端在实现远程调用的时候就必须考虑这些API的差异，分别查看A，B的API文档。

如果有个权威性协议作为规范做指导，规定这个API应该实现成下面这样，那么第三方客户端也只需按照这个标准去调用远程API，而不用查看A，B的API文档：

[http://A/api/person/\{001\}][http_A_api_person_001 1]

解释了这么多，就是为了引出：OData是这样的一个设计和使用Restful API 的权威性协议. OData定义了一些标准规则（像一个接口定义一堆方法一样），实现Restful API时候，必须实现这些标准规则（就像实现一个接口必须实现其所有方法一样）。第三方就可以根据Odata协议定义的规则去访问Restful API。

REST 构建的系统其系统的扩展能力要强于 SOAP，这可以体现在它的统一接口抽象、代理服务器支持、缓存服务器支持等诸多方面, 而SOAP的成熟性可以给需要提供给多开发语言的，多传输方式的，对于安全性要求较高的接口设计带来便利。

[Link 1]: https://baike.baidu.com/item/%E7%BA%A6%E6%9D%9F%E6%9D%A1%E4%BB%B6
[Link 2]: https://baike.baidu.com/item/%E4%BA%91%E8%AE%A1%E7%AE%97
[POST]: https://baike.baidu.com/item/POST
[DELETE]: https://baike.baidu.com/item/DELETE
[http_A_api_person_001]: http://a/api/person/001
[http_A_api_person_id_001]: http://a/api/person/id=001
[http_A_api_person_001 1]: http://a/api/person/%7b001%7d