历史、设计与未来¶

这个项目的历史是什么？它似乎在几周内从无到有，变得非常出色……

这里有一些关于这段历史的内容。

替代方案¶

多年来，我一直在为具有复杂需求的API（机器学习、分布式系统、异步任务、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 有一个光明的未来。

并且你的帮助非常受欢迎。