历史、设计与未来¶

这个项目的由来是什么？它似乎在一周内就从无到有，变得很棒了 [...]

以下是关于其历史的一些内容。

替代方案¶

我一直在使用复杂要求创建 API 已经好几年了（机器学习、分布式系统、异步作业、NoSQL 数据库等），并领导着多个开发人员团队。

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

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

正如替代方案部分中所述

如果没有前人的工作，FastAPI 将不存在。

之前已经有很多工具创建，它们帮助激发了它的创建。

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

但在某个时刻，除了创建能够提供所有这些功能的东西之外，别无选择，这需要从之前的工具中吸取最好的想法，并以最好的方式将它们结合起来，使用之前甚至不存在的语言特性（Python 3.6+ 类型提示）。

调查¶

通过使用所有之前的替代方案，我有机会从它们中学习，汲取想法，并以我认为对自己和与我一起工作的开发人员团队来说最好的方式将它们结合起来。

例如，很明显，它应该基于标准 Python 类型提示。

此外，最好的方法是使用现有的标准。

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

设计¶

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

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

根据最新的 Python 开发人员调查，它覆盖了大约 80% 的用户。

这意味着 FastAPI 专门针对 80% 的 Python 开发人员使用的编辑器进行了测试。由于大多数其他编辑器的工作原理相似，因此它的所有优势几乎适用于所有编辑器。

这样，我就能找到尽可能减少代码重复、在所有地方实现自动完成、类型和错误检查等最佳方法。

以一种为所有开发人员提供最佳开发体验的方式。

要求¶

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

然后我为它做出了贡献，使其完全符合 JSON Schema，支持以不同的方式定义约束声明，并基于对几个编辑器的测试来改进编辑器支持（类型检查、自动完成）。

在开发过程中，我还为 Starlette 做出了贡献，这是另一个关键要求。

开发¶

当我开始创建**FastAPI**本身时，大部分组件已经到位，设计已经确定，需求和工具已经准备就绪，对标准和规范的了解也清晰而新鲜。

未来¶

到目前为止，**FastAPI**及其理念已经为许多人所用，这一点已经很清楚了。

它正被选为更适合许多用例的替代方案。

许多开发人员和团队已经依赖**FastAPI**来进行他们的项目（包括我和我的团队）。

但仍然有许多改进和功能即将推出。

**FastAPI**拥有光明的未来。

并且您的帮助将不胜感激。