Tim Berners-Lee(蒂姆·伯纳斯-李)：我当初设想中的 Web，我们至今还没有真正看到。未来依然远比过去更加宏大。
概述
从前，Web 世界还很小，也很简单。
开发者们乐此不疲地把 PHP、HTML 和 MySQL 调用一股脑儿塞进同一个文件里，
然后自豪地告诉所有人去看看他们的网站。
但随着时间推移，Web 逐渐发展成拥有数十亿，
不，是数万亿页面的庞然大物，最初的游乐场也变成了一个主题公园般的元宇宙。
在本章中，我将指出一些在现代 Web 中变得越来越重要的领域：
下一章将展示 Python 在这些方面能够提供的能力。
随后，我们将深入探讨 FastAPI 这个 Web 框架，看看它能为我们带来什么。
服务和API
Web 是一个强大的连接纽带。
尽管大量活动仍然发生在内容层面，HTML、JavaScript、图像等等，
但人们正越来越重视用于连接各个系统的应用程序接口（API）。
通常，一个 Web 服务负责底层的数据库访问以及中间层的业务逻辑（通常统称为后端），
而 JavaScript 或移动应用则提供丰富的顶层前端（交互式用户界面）。
前后端这两个世界变得越来越复杂、分化也越来越明显，开发者通常需要专注于其中一端。
相比过去，成为一名全栈开发者要困难得多。
这两个世界通过 API 相互通信。
在现代 Web 中，API 的设计与网站本身的设计同样重要。
API 是一种契约，类似于数据库模式。
定义和修改 API，如今已经成为一项重要的工作。
API的种类
每个 API 都定义了以下内容：
随着技术从孤立的机器发展到多任务系统，再到联网服务器，多种 API 方法也随之演进。
你很可能在某个阶段遇到其中的一种或多种，
因此在介绍本书重点关注的 HTTP 及其相关技术之前，先做一个简要概述：
- 在网络出现之前，API 通常意味着非常紧密的连接，比如在与你的应用程序使用同一种语言的库中进行函数调用，例如在数学库中计算平方根。
- 远程过程调用（RPC）被发明出来，用于像调用本地应用中的函数一样，调用同一台机器或其他机器上不同进程中的函数。一个当前流行的例子是 gRPC。
- 消息传递通过管道在进程之间发送小块数据。消息可以是类似动词的命令，也可以只是表示感兴趣的、类似名词的事件。
当前流行的消息传递解决方案（从工具包到完整服务器，形式差异很大）包括 Apache Kafka、RabbitMQ、NATS 和 ZeroMQ。通信可以遵循不同的模式：
- 请求-响应：一对一，例如 Web 浏览器调用 Web 服务器。
- 发布-订阅（pub-sub）：发布者发送消息，订阅者根据消息中的某些数据（例如主题）对每条消息作出响应。
- 队列：类似于发布-订阅，但在一组订阅者中，只有一个会获取该消息并对其进行处理。
这些方式中的任何一种都可以与 Web 服务配合使用。
例如，用来执行发送电子邮件或生成缩略图这样的慢速后端任务。
HTTP
Tim Berners-Lee(蒂姆·伯纳斯-李) 为他的万维网提出了三个组成部分：
- HTML：一种用于展示数据的语言。Vue，React，Angular都是用来写页面的。
- HTTP：一种客户端—服务器协议。用于规范数据该如何传输，如何封装和解析。
尽管事后看来这些设计显得理所当然，但事实证明，它们的组合异常有用。
随着 Web 的发展，人们不断进行各种尝试，
其中一些想法，比如 IMG 标签，在达尔文式的竞争中存活了下来。
而随着需求逐渐明朗，人们也开始认真地制定相关标准。
REST风格API
Roy Fielding(罗伊·菲尔丁) 的博士论文中有一章定义了
表述性状态转移（Representational State Transfer，REST），
一种基于 HTTP 使用方式的架构风格。
尽管 REST 经常被提及，但它在很大程度上一直被误解。
一种大致被广泛采用的架构已经演进并主导了现代 Web。
它被称为 RESTful，具有以下特征：
资源是你可以加以区分并对其执行操作的数据。
Web 服务会为其希望暴露的每一个功能提供一个端点，
一个明确的 URL 和 HTTP 动词（操作）。
端点也被称为路由，因为它将 URL 路由到某个函数。
数据库用户都熟悉 CRUD 这一组操作缩写：
创建（create）、读取（read）、更新（update）、删除（delete）。
HTTP 动词同样非常符合 CRUD 思路：
客户端会向 RESTful 端点发送请求，
请求数据可以位于 HTTP 消息的以下位置之一：
作为响应，HTTP 会返回以下内容：
- 响应体，可能为空、单一内容，或以分块形式返回（按连续片段传输）
至少有一个状态码算是一个彩蛋：418（我是一个茶壶），当一个联网的茶壶被要求煮咖啡时，理论上就应该返回这个状态码。
你会发现有很多关于 RESTful API 设计的网站和书籍，它们都提供了有用的经验法则。
本书也会在行文过程中逐步介绍其中的一些。
JSON和API数据格式
前端应用可以与后端 Web 服务交换普通的 ASCII 文本，
但要如何表达诸如“事物列表”这样的数据结构呢？
正当我们真正开始需要它的时候，JavaScript Object Notation（JSON） 出现了。
这是另一个解决了重要问题的简单想法，事后看来几乎显而易见。
虽然其中的 J 代表 JavaScript，但它的语法看起来也很像 Python。
JSON 在很大程度上已经取代了诸如 XML 和 SOAP 这样的早期方案。
在本书接下来的内容中，你会看到 JSON 是 Web 服务默认的输入和输出格式。
JSON:API
现在，RESTful 设计和 JSON 数据格式的结合已经很常见了。
但仍然存在一些模糊空间，容易引发争议和技术争论。
最近的 JSON:API 提案旨在稍微收紧规范。
本书将采用较为宽松的 RESTful 方法，但如果你遇到较大的争议，
使用 JSON:API 或其他类似的严格规范可能会有所帮助。
GraphQL
对于某些用途，RESTful 接口可能显得繁琐。
Facebook（现为 Meta）设计了 Graph Query Language（GraphQL），
以便指定更灵活的服务查询。
本书不会深入讨论 GraphQL，但如果你发现 RESTful 设计无法满足你的应用需求，
可以考虑了解一下 GraphQL。
并发
除了服务化的增长，连接到 Web 服务的数量的快速扩展
也要求不断提高效率和可扩展性。
我们希望减少以下两项：
在早期的 Web 时代，人们曾梦想支持数百个并发连接，
然后为“10K 问题”而忧虑，而现在则假设一次能处理数百万个连接。
并发（concurrency）这个术语并不意味着完全并行。
在单个 CPU 上，并不会在同一个纳秒内发生多重处理。
相反，并发主要是为了避免忙等待（在响应返回之前让 CPU 空转）。
CPU 非常快，但网络和磁盘要慢上成千上万倍。
因此，每当我们与网络或磁盘通信时，都不希望只是干等着它们返回结果。
普通的 Python 执行是同步的：
一次只做一件事，按照代码指定的顺序执行。
有时我们希望采用异步方式：
先做一点这件事，再做一点另一件事，然后再回到第一件事，如此往复。
如果所有代码都在使用 CPU 进行计算（CPU 密集型），
实际上就没有多余时间来实现异步。
但如果我们执行的是让 CPU 等待外部操作完成的事情（I/O 密集型），
就可以采用异步方式。
异步系统提供了一个事件循环：
对耗时操作的请求会被发送并记录下来，
但我们不会为了等待它们的响应而阻塞 CPU。
相反，在事件循环的每一次迭代中都会执行一些即时处理，
而在这段时间内返回的任何响应，都会在下一次循环中被处理。
这种效果可能非常显著。
在本书的后续内容中，你会看到 FastAPI 对异步处理的支持
是如何让它比典型的 Web 框架快得多。
异步处理并不是魔法。
你仍然需要小心，避免在事件循环中执行过多的 CPU 密集型工作，
因为那会拖慢整体性能。
在本书后面的内容中，你会看到 Python 的 async 和 await 关键字的用法，
以及 FastAPI 是如何让你同时混合使用同步和异步处理的。
分层
《怪物史瑞克》的粉丝或许还记得，史瑞克提到自己有层层叠叠的个性，对此驴子回答道：“像洋葱一样？”
好吧，如果食人魔和让人流泪的蔬菜都有层次，那么软件当然也可以有层次。
为了管理规模和复杂性，许多应用长期以来一直采用所谓的三层模型。
这并不是什么新鲜事。
术语可能有所不同，但在本书中我将使用如下这种简单的术语划分（见图 1-1）：
- Web：基于 HTTP 的输入/输出层，负责组装客户端请求、调用服务层并返回响应
- Web client：Web 浏览器或其他基于 HTTP 的客户端软件
- Database：数据存储，通常是 SQL 或 NoSQL 服务器
这些组件将帮助你在无需从头开始的情况下扩展你的站点。
它们不是量子力学定律，所以可以将它们视为本书阐述的指导原则。
各层之间通过 API 进行通信。
这些 API 可以是简单的函数调用，跨不同的 Python 模块，
也可以通过其他方式访问外部代码。
如前所述，这可能包括 RPC、消息等。
在本书中，我假设使用单一的 Web 服务器，
Python 代码通过导入其他 Python 模块来进行操作。
模块负责处理分离和信息隐藏。
Web 层是用户通过客户端应用和 API 看到的层。
我们通常讨论的是一个 RESTful Web 接口，
包含 URL 以及 JSON 编码的请求和响应。
但也可以在 Web 层旁边构建替代的文本（或命令行接口，CLI）客户端。
Python 的 Web 代码可以导入服务层模块，但不应导入数据层模块。
服务层包含了网站提供的实际功能细节。
这个层实际上看起来像一个库。
它导入数据层模块以访问数据库和外部服务，但不应该了解这些细节。
数据层通过文件或对其他服务的客户端调用，为服务层提供对数据的访问。
也可能存在替代的数据层，它们与同一个服务层进行通信。
Model 框并不是一个实际的层，而是一个由各层共享的数据定义来源。
如果你在各层之间传递的是 Python 内置的数据结构，那么就不需要它。
正如你将看到的那样，FastAPI 集成了 Pydantic，
使得定义具备许多有用特性的数据结构成为可能。
为什么要进行这样的划分？
原因有很多，其中包括每一层都可以：
- 被替换或补充：例如，你可以在现有的 Web 层旁边，再添加一个使用不同 API（如 gRPC）的第二个 Web 层
遵循《捉鬼敢死队》里的一条规则：不要交叉水流。
也就是说，不要让 Web 层的细节泄露到其他层，
也不要让数据层的数据库细节泄露出去。
你可以将这些层想象成一个垂直堆叠的结构，就像《英国烘焙大赛》里的蛋糕一样。
下面是进行分层的一些原因：
- 如果你不进行分层，就会遇到一个广为流传的 Web 梗：现在你有两个问题了。
- 如果代码逻辑变得混乱，你将需要掌握两种或更多专业知识，才能理解并编写测试。
顺便说一句，虽然我把它们称为“层”，
但你并不需要假设某一层在另一层的“上面”或“下面”，
也不必认为指令会顺着重力方向流动。
这种垂直至上主义可不太好！
你也可以把这些层看作是彼此横向通信的盒子（见图 1-2）。
无论你如何对它们进行可视化，盒子/层之间唯一的通信路径都是那些箭头（API）。
这一点对测试和调试非常重要。
如果工厂里存在未记录的暗门，夜班保安迟早会被吓一跳。
Web 客户端与 Web 层之间的箭头使用 HTTP 或 HTTPS 传输，
内容主要是 JSON 文本。
数据层与数据库之间的箭头使用数据库特定的协议，
并承载 SQL（或其他）文本。
各层之间的箭头则是携带数据模型的函数调用。
另外，沿着这些箭头流动的推荐数据格式如下：
- 客户端 ⇔ Web：使用 JSON 的 RESTful HTTP
基于我自己的经验，我选择用这种方式来组织本书的主题结构。
它是可行的，也已经在相当复杂的网站中得到了验证，但并非不可改变。
你也许会有更好的设计！
无论你采用哪种方式，以下这些要点都很重要：
有时候，决定代码最适合放在哪一层并不容易。
例如，第 11 章将探讨认证和授权的需求，
以及如何实现它们，
是作为 Web 层和 Service 层之间的一个额外层，
还是放在其中某一层内部。
软件开发有时既是一门科学，也是一门艺术。
数据
Web 常常被用作关系型数据库的前端，
尽管也已经发展出了许多其他的数据存储和访问方式，
例如 NoSQL 或 NewSQL 数据库。
但除了数据库之外，机器学习（ML），或者说深度学习，甚至统称为 AI，
正在从根本上重塑技术格局。
大型模型的开发需要大量对数据的折腾，
这在传统上被称为提取、转换、加载（ETL）。
作为一种通用的服务架构，
Web 可以帮助处理机器学习系统中的许多繁琐细节。
总结
Web 使用了大量 API，尤其是 RESTful API。
异步调用可以实现更好的并发性，从而加快整体处理速度。
Web 服务应用通常规模足够大，可以划分为多个层次。
数据本身也已经成为一个重要的独立领域。
所有这些概念都将在下一章中通过 Python 编程语言来介绍。
录播课，直播课报名，领取电子，笔记，源码等，可以添加助教微信 yggaibc 有任何问题可以评论区留言讨论，我看到了会第一时间回复。
10个月宝宝每天需要喝多少奶粉？
