历史、设计与未来¶

这个项目有什么历史？它似乎在几周内突然变得很棒了 [...]

以下是它的一些历史。

替代方案¶

我多年来一直在创建具有复杂要求（机器学习、分布式系统、异步任务、NoSQL 数据库等）的 API，并领导了几个开发团队。

作为其中的一部分，我需要研究、测试和使用许多替代方案。

FastAPI 的历史在很大程度上是其前身的历史。

正如替代方案一节所述

如果没有他人的前期工作，FastAPI 就不会存在。

之前有许多工具的创建启发了它的诞生。

我多年来一直避免创建一个新的框架。起初，我试图使用许多不同的框架、插件和工具来解决 FastAPI 涵盖的所有功能。

但在某个时候，除了创建一个能提供所有这些功能、汲取先前工具的最佳思想并以最佳方式组合它们（利用之前甚至没有的语言特性，如 Python 3.6+ 类型提示）的工具之外，别无他选。

研究¶

通过使用所有这些之前的替代方案，我有机会从它们中学到东西，汲取想法，并以我能为自己和与我合作的开发团队找到的最佳方式将它们组合起来。

例如，很明显，理想情况下它应该基于标准的 Python 类型提示。

此外，最好的方法是使用已经存在的标准。

因此，在开始编写 FastAPI 的代码之前，我花了几个月时间研究 OpenAPI、JSON Schema、OAuth2 等规范。理解它们之间的关系、重叠和差异。

设计¶

然后我花了一些时间设计我作为用户（即使用 FastAPI 的开发者）想要的开发者“API”。

我在最流行的 Python 编辑器中测试了几个想法：PyCharm、VS Code、基于 Jedi 的编辑器。

根据最新的Python 开发者调查，这涵盖了大约 80% 的用户。

这意味着 FastAPI 是专门针对 80% Python 开发者使用的编辑器进行测试的。由于大多数其他编辑器的工作方式相似，其所有优点应该适用于几乎所有编辑器。

这样我就能找到最佳方式，尽可能减少代码重复，实现随处可见的代码补全、类型和错误检查等。

所有这些都以一种为所有开发者提供最佳开发体验的方式进行。

需求¶

在测试了几种替代方案后，我决定使用Pydantic，因为它有诸多优点。

然后我为其贡献代码，使其完全符合 JSON Schema，支持不同的方式定义约束声明，并根据在多个编辑器中的测试改进了编辑器支持（类型检查、自动补全）。

在开发过程中，我还为Starlette（另一个关键需求）贡献了代码。

开发¶

当我开始创建 FastAPI 本身时，大部分组件已经就绪，设计已经确定，需求和工具也已准备好，并且对标准和规范的知识清晰而新颖。

未来¶

至此，FastAPI 及其理念对许多人来说已经证明是有用的。

它在许多使用场景中比之前的替代方案更合适，因此被选择。

许多开发者和团队（包括我和我的团队）的项目已经依赖 FastAPI。

但仍有许多改进和功能即将到来。

FastAPI 前途光明。

并且非常感谢您的帮助。