Web 服务架构类型

发表于 更新于 分类于 阅读次数：

根据 Web 应用架构设计的风格，可以将 Web 服务划分为以功能为中心的服务以及以资源为中心的服务。

以功能为中心的服务

以功能为中心的 Web 服务历史由来已久，它是指能够调用远程机器上的功能或者对象方法，而无须知道这些功能或者对象是如何实现的。
我们了解的 CORBA（公共对象请求代理体系架构），XML - RPC（可扩展标记语言——远程过程调用），DCOM（分布式组件对象模型），SOAP（简单对象访问协议）等技术都是关注于如何让客户端代码调用一个在远程机器上实现的功能。
本文我们重点讲述 SOAP 协议。

SOAP

SOAP 基于 XML 和 HTTP，使用 XML 来实现消息描述，使用 HTTP 实现消息传输。SOAP 最重要的一个特性是允许 Web 服务基于自身的约定描述完成服务发现并生成集成代码。

图1所示为 SOAP 的工作原理。


图1：SOAP 的工作原理

Web 服务提供者暴露一组 XML 资源，诸如 Web 服务定义语言（WSDL）文件，XML 模式定义（XSD）文件。WSDL 描述方法与可用的终端信息，XSD 描述请求与响应中用到的数据结构。这些资源文件就是 Web 服务的约定，客户端代码如何生成，Web 服务如何调用，这些必要的信息全部都在这些资源文件中。

举个例子，如果我们使用 Java 开发客户端，那么我们可以使用专门的工具和库，下载这些 Web 服务定义资源文件，然后生成 Java 本地客户端代码。这些代码就是一些 Java 类，可以被编译并用在应用程序中。在这些代码的背后，会依赖到 SOAP 相关的一些库，这些库封装了数据序列化，身份认证，路由，错误处理等各种实现细节。客户端无须知道自己调用的是远程 Web 服务，只需要简单地依赖基于 Web 服务约定（WSDL 和 XSD文件）生成的 Java 代码就可以使用这些远程服务器提供的功能了。

SOAP 的另一个重要的特性是其扩展性。一些高级特性，比如事务，身份认证，加密等已被集成到 SOAP 中。SOAP 的这些优点，使得 SOAP 在企业级应用中使用广泛，比如银行，保险之类的企业就大量使用了 SOAP。

然而，SOAP 对伸缩性却支持不够。我们知道，SOAP 请求是通过 XML 发送的，请求参数和方法名都在 XML 里面。URL 并不包含远程过程调用所需要的全部信息，响应也就没办法在 HTTP 层面基于 URL 进行缓存。也就是说，使用 SOAP 会使应用的伸缩性变差，应用没办法使用反向代理进行缓存。

以资源为中心的服务

开发 Web 服务的一个替代方案是将服务的关注点从功能转移到资源上。REST是一个面向资源架构风格的方案，早在 2000 年初就已经提出来。由于其简单和轻量级，REST 已逐渐变成 Web 服务事实上的标准。

REST 是 Roy Thomas Fielding 在他的 2000 年博士论文中提出的，Fielding 将他对互联网软件的架构原则，定名为 REST，即 Representational State Transfer 的缩写。
REST 中资源是指 Web 上一切可以识别的，可命名的，可以被找到并被处理的实体。REST 使用 URI（统一资源定位符）指向资源，使用 HTTP 请求方法操作资源。

REST 架构风格最重要的架构约束有如下5个。

  • 客户端-服务器端，即 Client / Server 的架构形式
  • 无状态，通信的会话状态由客户端负责维护，即请求中包含了全部必要的信息。如果服务器端保持会话，要么保证指定会话使用同一个服务器响应请求，要么创建一个保存会话数据的集中式存储系统
  • 缓存，由于无状态，故可以使用缓存来提高响应效率
  • 统一接口，每个 REST 应用都共享一种通用架构，接口的意义统一
  • 分层系统，根据单一职责将系统分层，常见的分层为：
    – 应用层：负责返回 JSON 数据
    – 服务层：为应用层提供服务支持
    – 数据层：提供数据存取服务

REST 就是这一系列设计约束的集合，如果一个架构符合 REST 原则，就称它为 RESTful 架构。

REST 不是一种技术，也不是一个标准 / 协议，而是一种使用既有标准（HTTP + URI + JSON）来实现其要求的架构风格。
与 REST 对应的不是 SOAP 协议，而是像 RPC 这样的架构风格，即上文我们说的以功能为中心的架构风格。

从 Web 服务发布者的角度看，REST 比 SOAP 更轻量，因为 REST 只需要创建一个在线 wiki 就可以了，在 wiki 里定义各种资源，每种资源的 HTTP 方法，以及请求响应的例子以展示数据格式。 REST 相比于 SOAP 的中另一个好处是无须再去管理 WSDL 及 XSD 这种十分复杂的 API 约定。
从客户端角度看，REST 既有优点也有缺点。客户端无法自动生成客户端代码及没法发现 Web 服务，这是缺点。但同时，REST 的方式也降低了使用者的难度，因为不再需要集成自动生成的代码了。
从安全的角度看， REST 服务没有 SOAP 服务控制的那么精细。上文提到 SOAP 其扩展性较好，已支持一大批附加的特性，例如事务，身份认证，加密等。
从伸缩性角度看， REST 服务是无状态的，意味着可以通过反向代理来处理热门资源，减轻 Web 服务和数据存取的负载压力。

小结

通过对两种 Web 服务类型的描述，我们看到 REST 并不一定就比 SOAP 好，REST 也不能取代 SOAP，REST 仅仅是在 SOAP 外提供的一个额外选择。
从大企业角度看，REST 并不成熟，扩展特性并不丰富。从创业公司看，SOAP 又太过笨重，严格，难以驾驭。这看人需要看我们具体应用的细节和系统集成的需求。

参考资料

  1. 互联网创业核心技术——构建可伸缩的Web应用，Artur Ejsmont 著，李智慧 何坤译，电子工业出版社，2016年
  2. Java RESTful Web Service 实战（第2版），韩陆 著，机械工业出版社，2016年
  3. Python Web 开发实践，董伟明著，电子工业出版社，2016年
  4. http://blog.csdn.net/zhuizhuziwo/article/details/8153327