历史、设计与未来¶

这个项目的历史是什么？它似乎在几周内横空出世，取得了巨大的成功……

这是其中一点历史。

替代方案¶

我曾多年来使用复杂的 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** 的未来一片光明。

而您的帮助将是巨大的财富。