OpenAPI 规范的下一步是什么?v4 如何才能在 OpenAPI v3 的成功基础上再接再厉?规范如何在人工智能和大型语言模型的背景下帮助解决问题?
随着 2023 年接近尾声,这些问题的答案开始成形。我们雄心勃勃地目标是 **在 2024 年底推出 v4 "月球漫步"**,这将是令人激动的一年。
由于任务艰巨,因此有必要确立一些指导原则。在回顾了去年提出的主要方案和讨论后,这些原则是 **语义**、**签名**、**包容性**、**组织**、**升级**,它们的顺序十分重要
-
- **🌖 语义提供目的**。仅仅描述 API 的机制是不够的,还必须描述其语义,无论消费者是人还是人工智能。语义将 **什么** *(...这有什么用?)* 和 **为什么** *(...这有什么意义?)* 与 **如何** *(...这怎么运作?)* 结合起来。
OpenAPI 帮助人们更快地构建更好的 API,而工具生态系统持续年复一年地创造更多价值。2023 年的新事物是新型 API 消费者 - 生成式人工智能的兴起。大型语言模型可以处理 OpenAPI 描述,然后利用该 API 解决问题。凭借生成式人工智能理解自然语言的能力,OpenAPI 可以帮助将 API 的强大功能带给非开发人员,实现前所未有的可访问性水平。为了充分实现这种潜力,API 生产者应该在其 HTTP 请求的机械描述中添加传达这些 API 操作的含义和目的的详细信息。这反过来也有助于人和大型语言模型获得更好的结果。
换句话说,人们几个世纪以来一直在用松散的自然语言相互交流,而我们几十年来一直在使用严格的编程语言与机器交流。大型语言模型弥合了松散和严格的世界之间的差距,这意味着大量以前无法使用 API 的人现在可以使用了。
无论您对生成式人工智能抱有什么看法,从过度炒作到改变世界,我们都可以预料到许多人将使用 OpenAPI 来驱动基于人工智能的 API 消费者。如果 OpenAPI 不提升自身来满足该社区的需求,他们就会寻找替代方案。
- **🌒 请签名!** API 代表一组函数,每个函数描述一个面向客户端的目的。函数可以通过其签名识别,该签名与一组 HTTP 交互相关联。月球漫步将这一概念置于其核心地位。
任何 HTTP API 始终都是达到某种目的的手段。API 消费者更喜欢重用现有功能,理想情况下,他们可以以最自然的方式了解该功能。PUT/PATCH/DELETE 返回 200 或 204 是一个实现细节,与它对客户端执行的功能相比相形见绌。如今,在 OpenAPI 中表达 API 函数签名的途径有限。pathItem 无法使用查询参数来区分操作。每个 HTTP 方法只能有一个操作。这些是由于缺乏对唯一签名的正式定义而对 API 函数签名施加的人为约束。OpenAPI 过去的工作重点是使开发人员能够描述 HTTP API。这重新排列了优先级,以便开发人员可以使用 OpenAPI 来定义具有唯一签名的 API 函数,然后将每个签名映射到 HTTP 机制。
- **🌖 语义提供目的**。仅仅描述 API 的机制是不够的,还必须描述其语义,无论消费者是人还是人工智能。语义将 **什么** *(...这有什么用?)* 和 **为什么** *(...这有什么意义?)* 与 **如何** *(...这怎么运作?)* 结合起来。
-
- **🌕 包容性需要一个大帐篷**:月球漫步旨在描述所有基于 HTTP 的 API。虽然它在 HTTP API 的设计方面保持中立,但它认识到拥有不同的设计风格和意见的重要性。
月球漫步应该能够描述开发人员可能已经拥有的 HTTP API,以及他们可能想要构建的 API。它应该能够将 API 函数的签名准确地映射到 API 提供的 HTTP 请求和响应的实际实例。月球漫步确实更倾向于面向资源的 API 风格,因为它们非常流行,但它应该能够描述纯粹的 RPC API,即使这些 API 签名是通过 HTTP 标头值或请求正文值来区分的。
- **🌕 包容性需要一个大帐篷**:月球漫步旨在描述所有基于 HTTP 的 API。虽然它在 HTTP API 的设计方面保持中立,但它认识到拥有不同的设计风格和意见的重要性。
-
- **🌗 通过关注点分离进行组织**。例如,API 的形状变化应该独立于 API 部署进行。API 部署可以使用不同的安全方案进行保护。API 函数的签名不应该与内容模式格式紧密耦合。
为了满足不断增长的客户群的各种需求,功能数量无疑会增加,从而带来更多复杂性。为了抵消这种影响,我们将对 API 描述不同方面的模块化应用更多严格性。我们将努力消除当前存在的歧义,并利用现有标准来最大程度地减少不必要的创新。我们的目标是为 API 描述消费者、作者和工具提供者提供更好的体验。
- **🌗 通过关注点分离进行组织**。例如,API 的形状变化应该独立于 API 部署进行。API 部署可以使用不同的安全方案进行保护。API 函数的签名不应该与内容模式格式紧密耦合。
-
- **🌑 机械升级**。OpenAPI v3 的一个重要原则是它提供了从 v2 的直接升级路径。月球漫步继承了这一点,这意味着它必须再次能够从 v3(以及 v2)机械地升级到月球漫步。
像 OpenAPI 这样的重要开源项目依赖于许多人的贡献。如果您像我们一样对上述想法或利用人工智能帮助更多人使用 API 的机会感到兴奋,请参与进来!一个很好的起点是加入我们每周四的电话会议(详情),欢迎任何想加入的人!