主流Web架构相互比较

Posted 2023-04-03 fireflypjj

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了主流Web架构相互比较相关的知识，希望对你有一定的参考价值。

做WEB好几年了，各种语言和技术都稍有涉猎。今天心血来潮，突然想总结⼀下。其实不论什么技术，什么需求，通常WEB开发就是通过WEB前端管理⼀个或⼤或⼩或独⽴或分布式的关系型数据库，很多东西都是相通的。这⾥说的WEB架构，是指WEB应⽤开发中每种技术独有的资源组织形式（包括⽂件，数据库，HTTP请求处理等。注意并⾮OO的开发⽅式才有架构⼀说），也许说开发⽅式更容易让⼈理解⼀些。

REST架构风格是全新的针对Web应用的开发风格，是当今世界最成功的互联网超媒体分布式系统架构，它使得人们真正理解了Http协议本来面貌。随着 REST架构成为主流技术，一种全新的互联网网络应用开发的思维方式开始流行。

REST是什么

REST是英文Representational State Transfer的缩写，中文翻译为“表述性状态转移”，他是由Roy Thomas Fielding博士在他的论文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。

基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规范的基础上增加新的规范，就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。

传统的Web应用大都是B/S架构，它包括了如下一些规范。

客户－服务器

这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。

无状态性

无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。

缓存

为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。

B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST。

REST在原有的架构上增加了三个新规范：统一接口，分层系统和按需代码。

WEB程序的架构基本上可以分成以下三类：

(⼀) 基于“WEB页⾯/⽂件”，例如CGI和php/ASP程序。程序的⽂件分别存储在不同的⽬录⾥，与URL相对应。当HTTP请求提交⾄服务器时，URL直接指向某个⽂件，然后由该⽂件来处理请求，并返回响应结果。

可以想像，我们在站点根⽬录的news⽬录下放置⼀个readnews.php文件。

这种开发⽅式最⾃然，最易理解，也是PHP最常⽤的⽅式。要注意产⽣的URL对搜索引擎不友好，不过你可以⽤服务器提供的URL重写⽅案来处理，例如Apache的mod_rewrite。

(⼆) 基于“动作”(Action)。这是MVC架构的WEB程序所采⽤的最常见的⽅式。⽬前主流的WEB框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都采⽤这种设计。URL映射到控制器(controller)和控制器中的动作(action)，由action来处理请求并输出响应结果。这种设计和上⾯的基于⽂件的⽅式⼀样，都是请求/响应驱动的⽅案，离不开HTTP。

可以想像在实际代码中，我们会有⼀个控制器newsController，其中有⼀个readAction。不同框架可能默认实现⽅式稍有不同，有的是⼀个Controller⼀个⽂件，其中有多个Action，有的是每个Action⼀个⽂件。当然这些你都可以⾃⼰控制，题外话。

这种⽅式的URL通常都很漂亮，对搜索引擎友好，因为很多框架都⾃带有URL重写功能。可以⾃由规定URL中controller、action及参数出现的位置。

另外，还有更直接的基于URL的设计⽅案，那就是REST。通过⼈为规定URL的构成形式（⽐如Action限制成只有⼏种）来促进⽹站之间的互相访问，降低开发的复杂性，提⾼系统的可伸缩性。REST对于Web Services来说是⼀个创新。

虽然本⽂讨论的是单个项⽬所采⽤的架构，⽽REST是为了解决⽹站之间的通讯问题，但REST的出现，会对单个项⽬的架构造成影响（很显然你在开发时就要构造规范的URL）。将来混⽤REST和MVC应该也是⼀种趋势。RoR提供很好的REST⽀持，Zend Framework也提供了Zend_Rest来⽀持REST，包括Server和Client。

(三) 基于“组件”（Component ，GUI设计也常称控件）、事件驱动的架构，最常见的是微软的.NET。基本思想是把程序分成很多组件，每个组件都可以触发事件，调⽤特定的事件处理器来处理（⽐如在⼀个html按钮上设置onClick事件链接到⼀个PHP函数）。这种设计远离HTTP，HTTP请求完全抽象，映射到⼀个事件。

事实上这种设计原本最常应⽤于传统桌⾯GUI程序的开发，例如Delphi，Java Swing等。所有表现层的组件⽐如窗⼝，或者HTML表单都可以由IDE来提供，我们只需要在IDE⾥点击或拖动⿏标就能够⾃动添加⼀个组件，并且添加⼀个相应的事件处理器。

这种开发⽅式有⼏个优点：

复⽤性 -代码⾼度可重⽤。

易于使⽤ -通常只需要配置控件的属性，编写相关的事件处理函数。

我个⼈也挺喜欢这种⽅式，PEAR就提供了相当强⼤的HTML_QuickForm，用于在页面添加表单元素及其事件处理函数，还可以与Smarty等模板引擎相结合。这对于项⽬开发来说是⼀个补充性的功能，在项⽬中的某些部份使⽤QuickForm，有时可以⼤⼤加快开发。

REST、SOAP、XML-RPC是常用的Web接口标准。其中REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存来提高响应速度，在性能、效率和易用性上都优于SOAP协议。

REST风格的接口可以使用各种语言（如Java、PHP和javascript）进行调用，也可以直接使用HTTP客户端进行调用，这种简便性让用户能够与之直接交互，使用Web浏览器构建一个GET URL并读取返回的内容，方便调试和测试。

REST架构让人们易于理解网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除，正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。

REST架构风格的核心特征就是强调组件之间有一个统一的接口，其目的是为了降低开发的复杂性，提高系统的可伸缩性，保证系统提供的服务都是解耦的，从而改善了系统的交互性和可重用性。

既然REST这么好用，那么是不是所有的Web应用都能采取此种架构呢？答案是否定的。我们知道，直到现在为止，MVC(Model-View-Controller) 模式依然是Web开发最普遍的模式，绝大多数的公司和开发人员都采取此种架构来开发Web应用，并且其思维方式也停留于此。MVC模式由数据，视图和控制器构成，通过事件(Event)触发Controller来改变Model和View。加上Webwork,Struts等开源框架的加入，MVC开发模式已经相当成熟，其思想根本就是基于Action来驱动。从开发人员角度上来说，贸然接受一个新的架构会带来风险，其中的不确定因素太多。并且REST新的思维方式是把所有用户需求抽象为资源，这在实际开发中是比较难做到的，因为并不是所有的用户需求都能被抽象为资源，这样也就是说不是整个系统的结构都能通过REST的来表现。所以在开发中，我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC，因为这适合绝大多数的Web应用开发，开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式，而对其它需求采取MVC开发即可。这里需要提到的就是ROR(Ruby on Rails)框架，这是一个基于Ruby语言的越来越流行的Web开发框架，它极大的提高了Web开发的速度。更为重要的是，ROR(从1.2版本起)框架是第一个引入REST做为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的 REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好的构建Web应用。

对开发人员来说，REST不仅仅在Web开发上贡献了自己的力量，同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上。

4 种主流的 API 架构风格对比

作者 | AltexSoft
译者 | 朱琪珊策划 | 万佳
来源：InfoQ 架构头条（id：ArchFront）

本文讨论了四种主要的 API 架构风格，比较它们的优缺点，并重点介绍每种情况下最适合的 API 架构风格。

两个单独的应用程序需要中介程序才能相互通信。因此，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。

为了快速、大规模地集成不同的应用程序，API 使用协议或规范来定义那些通过网络传输的消息的语义和信息。这些规范构成了 API 的体系结构。

在过去，人们已经发布了多种不同的 API 架构风格。每个架构风格都有它独有的标准化数据交换的模式。这一系列的 API 架构风格的选项，引发了大量的关于哪种架构风格才是最好的争论。

今天，许多 API 的使用者将 REST 称作“消亡的 REST”（REST in peace），并且为 GraphQL 感到欢欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的赢家。这些观点的问题在于，它们的出发点只是为某种技术背书，而不是去考虑它实际的属性和特性如何与当前的需求相匹配。

1RPC：调用另一个系统的函数

远程过程调用是一种允许在不同上下文中远程执行函数的规范。RPC 扩展了本地过程调用的概念，并将其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在问题的，因为很难确保 XML 有效负载的数据类型。因此，后来 RPC API 开始使用一个更具体的 JSON-RPC 规范，该规范被认为是 SOAP 的更简单的替代方案。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运行状况检查和身份验证，它非常适合连接不同的微服务。

RPC 的工作机制

客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接受到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。

RPC 的优势

简单直接的交互。 RPC 使用 GET 来获取信息，使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。

易于添加新函数。 如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并获取符合其需求的信息。

高性能。轻量级的有效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得非常高效。

RPC 的不足

和底层系统紧密耦合。 API 的抽象级别有助于其可重用性。API 与基础系统的耦合越紧密，对其他系统的可重用性就越差。RPC 与基础系统的紧密耦合不允许其在系统函数和外部 API 之间建立抽象层。这很容易引起安全问题，因为关于基础系统的细节实现很容易会泄漏到 API 中。

RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此，客户端要么会担心调用特定端点的带来的任何可能的副作用，要么需要尝试弄清楚要调用的端点，因为客户端不了解服务器如何命名其函数。

可发现性低。 在 RPC 中，无法对 API 进行检验总结，或者发送请求来开始理解根据需求应该调用哪个函数。

函数爆炸性增长。创建新函数非常容易。因此，相较于重新编辑现有的函数，我们会倾向于创建新的功能，最终产生大量难以理解的、功能重叠的函数。

RPC 的用例

RPC 模式在八十年代开始使用，但这并不意味着它已经过时了。诸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）这样的大公司如今正在内部使用高性能的 RPC 版本，来执行极高性能、低开销的消息传递。它们庞大的微服务系统要求内部通信在使用短消息的情况下也保持清晰。

命令 API。RPC 是用于将命令发送到远程系统的正确选择。例如，Slack API 是非常以命令为中心的：加入频道、离开频道、发送消息。因此，Slack API 的设计者以类似于 RPC 的样式对其进行了建模，使其小巧、紧凑并且易于使用。

用于内部微服务的客户特定的 API。由于是在单个提供者和单个使用者之间建立直接的集成，我们不想像 REST API 那样，花太多时间通过网络传输大量的元数据。凭借高消息速率和消息性能，gRPC 和 Twirp 成为了用于微服务的可靠用例。通过在底层使用 HTTP 2，gRPC 能优化网络层，使其非常高效地在不同服务之间每天传送大量信息。然而，如果你并不是要着眼于提高网络性能，而是要在发布高度独立的微服务团队之间建立一个稳定的 API 联系。REST 就能做到。

2SOAP：使数据作为服务可用

SOAP 是一个 XML 格式的、高度标准化的网络通讯协议。在 XML-RPC 发布的一年后，SOAP 由微软发布、并继承了许多 XML-RPC 的特性。在 REST 紧随其后发布，一开始它们是被同时使用，但很快 REST 赢得了这次比赛，成为了更流行的协议。

SOAP 的工作机制

XML 数据格式拖累了很多数据规范。伴随着大量的消息结构，XML 数据格式使得 SOAP 成为了最冗长的 API 架构风格。

SOAP 的消息由这些部件组成：

一个信封标签：用于开始和结束每条消息
包含请求或响应的正文
一个标头：用于表示消息是否由某些规范或额外要求的来确认
故障通知：包含了可能在请求处理过程只能够发生的任何错误

SOAP API 的逻辑由 Web 服务描述语言（WSDL）编写。该 API 描述语言定义了端点并描述了可以执行的所有过程。这使得不同的编程语言和 IDE 能够快速建立通信。

SOAP 支持有状态和无状态消息传递。在有状态的情况下，服务器存储接收到的信息可能非常繁琐复杂。但这对于涉及多方和复杂交易的操作是合理的。

SOAP 的优势

独立于语言和平台。内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。

绑定到各种协议。SOAP 在适用于多种场景的传输协议方面是十分灵活的。

内置错误处理。SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息。

一系列的安全拓展。SOAP 与 ES-Security 集成，因此 SOAP 可满足企业级事务要求。它在事务内部提供了隐私和完整性，同时允许在消息级别进行加密。

SOAP 的不足

如今，由于如下几种原因，许多开发人员在听到必须集成 SOAP API 的想法后都会感到不安。

仅使用 XML。SOAP 消息包含大量的元数据，并且在请求和响应时仅支持繁冗的 XML 格式。

重量级。由于 XML 文件的大小，SOAP 服务需要很大的带宽。

非常专业化的知识。构建 SOAP API 服务器需要对所有涉及到的协议以及它们及其严格的限制都有很深的了解。

乏味的消息更新。由于需要额外的工作来添加或者删除某个消息属性，这种死板的 SOAP 模式减慢了其被采用的速度。

SOAP 的用例

目前，SOAP 体系结构最常用于企业内部或与其信任的合作伙伴的内部集成。

高度安全的数据传输。SOAP 严格的消息结构，安全性和授权功能使其成为在 API 和客户端之间执行正式软件协议的最合适的选择，同时又符合 API 提供者与 API 使用者之间的法律合同。这就是为什么金融组织和其他企业用户选择适用 SOAP 的原因。

3REST：使数据作为资源可用

REST 如今是一种无需解释的 API 架构风格，它由一系列的架构约束所定义，旨在被广泛 API 使用者采用。

当前最常见的 API 架构风格最初时由 Roy Fielding 在其博士论文中提出的。REST 使得服务端的数据可用，并以简单的格式（通常是 JSON 和 XML）来表示它。

REST 的工作机制

REST 的定义并不像 SOAP 那样严格。RESTful 体系结构应该遵守如下六个体系结构约束：

统一接口：无论设备或应用程序类型如何，都可以采用统一的方式与给定的服务端进行交互。
无状态：请求本身包含处理该请求所需要的状态，并且服务端不存储与会话相关的任何内容。
缓存
客户端 - 服务器体系结构：允许双方独立发展
应用程序的层级系统
服务端向客户端提供可执行代码的能力

实际上，某些服务仅在某种程度上是 RESTful 的。而它们的内核采用了 RPC 样式，将较大的服务分解为资源，并有效地使用 HTTP 基础结构。但 REST 的关键部分是超媒体（又称 HATEOAS），是超文本作为应用程序状态引擎（Hypertext As The Enginer Of Application State）的缩写。

基本来说，这意味着 REST API 在每个响应中都提供元数据，该元数据链接了有关如何使用该 API 的所有相关信息。这样便可以使客户端和服务端解耦。因此，API 提供者和 API 使用者都可以独立发展，而这并不会阻碍他们的交流。

“HATEOAS 才是 REST 的关键功能，因为它真正使得 REST 成为 REST。但由于大多数人不使用 HATEOAS，因此他们实际上是在使用 HTTP RPC。”这是 Reddit 上表达的一些激进观点。确实，HATEOAS 是 REST 的最成熟版本。

但是，这非常难以实现，因为这要求 API 客户端要比它们如今构建和使用的方式变得更先进和智能得多。因此，即便是如今非常好的 REST API 也不一定总是能做到这一点。这就是为什么 HATEOAS 主要是作为 RESTful API 设计的长期开发的愿景而存在。

当服务端实现 REST 的某些功能和 RPC 的某些功能时，在 REST 和 RPC 之间确实可能存在这样一个灰色区域。但 REST 是基于资源或名词的，而不是基于动作或动词。

在 REST 中，使用例如 GET、POST、PUT、DELETE、OPTIONS 可能还有 PATCH 等 HTTP 方法来完成操作。

REST 的优势

客户端和服务端的解耦：由于 REST 尽可能地解耦了客户端和服务端，REST 相较于 RPC 可以提供更好的抽象性。具有抽象级别的系统能够封装其实现细节，以更好的标示和维持它的属性。这使得 REST API 足够灵活，可以随着时间的推移而发展，同时保持稳定的系统。

可发现性：客户端和服务端之间的通信描述了所有内容，因此不需要外部文档即可了解如何与 REST API 进行交互。

缓存友好：REST 重用了许多 HTTP 工具，也是唯一一种可以在 HTTP 层面上缓存数据的 API 架构风格。与其相对的是，在任何其他 API 上实现缓存都需要配置其他缓存模块。

多种格式支持：REST 拥有支持多种格式用于存储和交换数据的能力，这是它如今成为搭建公共 API 的主要选择的原因之一。

REST 的不足

没有标准的 REST 结构：在构建 REST API 方面，没有具体的正确方法。如何对资源进行建模以及哪些资源需要建模取决于不同的情况。这使得 REST 在理论上很简单，但在实践中却很困难。

庞大的负载： REST 会返回大量丰富的元数据，以便客户端可以仅从响应中了解有关应用程序状态的所有必要信息。对于具有大量带宽容量的大型网络系统来说，这种“啰嗦”的通信并不算很大的负载。但带宽容量并非总是足够的。这也是 Facebook 在 2012 年提出 GraphQL 架构风格的关键驱动因素。

响应过度和响应不足问题。REST 的响应包含的数据会过多或不足，通常会导致客户端需要发送另一个请求。

REST 的用例

管理 API。在系统中，专注于管理对象并面向许多使用者的 API 是最常见的 API 类型。REST 帮助此类 API 具有强大的可发现性，良好的文档编制，因此 REST 非常适合此对象模型。

简单的资源驱动型应用程序。在用于连接不需要查询灵活性的资源驱动型应用时，REST 是一种非常有效的方法。

4GraphQL：仅请求所需要的数据

REST API 需要被多次调用才能返回所需要的资源。所以，GraphQL 被发明了，并改变了这一切游戏的规则。

GraphQL 是一种语法，它描述了如何进行精确的数据请求。有些应用程序的数据模型具有许多相互引用的复杂实体，在这种情况下，实现 GraphQL 是值得的。

如今，GraphQL 的生态系统正在蓬勃发展，出现了例如 Apollo、GraphiQL 和 GraphQL Explorer 等强大的库和工具。

GraphQL 的工作机制

GraphQL 从构建模式（Schema）开始。模式是对于用户可以在 GraphQL API 中进行的所有查询及其返回的所有类型的描述。模式构建非常困难，因为它需要使用模式定义语言（SDL）进行强类型化。

因为在客户端进行查询之前已经定义好了模式，所以客户端可以验证其查询语句，以确保服务端能够对查询语句进行响应。在查询语句到达后端应用程序时，GraphQL 操作将根据整个模式进行解释，并向前端应用程序返回解析到的数据。API 向服务端发送一个庞大的查询，该 API 返回一个仅包含我们所需数据的 JSON 响应。