随着 OpenAPI 规范 3.0 版本即将进入 Beta 候选阶段，这一系列文章旨在从技术开发者社区 (TDC) 的角度提供对变化内容和方式的见解。第一篇文章描述了规范下一阶段演进背后的背景和基本原理，第二篇文章涵盖了结构性变化，接下来的几篇文章将探讨协议、文档和其他剩余的开放事项。
请求参数
在 OpenAPI 2.0 中，请求消息中所有可能变化的部分，包括 URL 参数、标头和主体，都被描述为一组类型化的参数。经验表明，将 HTTP 请求主体的描述映射到与查询和标头参数相同的元数据集中会带来一些挑战。今天，让我们来分解这将如何影响请求主体、内容对象和 Cookie 参数。
请求主体
一个新的属性requestBody已添加到操作对象中。作为一个命名属性，这提供了与参数对象更好的区分并简化了它，此外，它也使描述请求主体本身变得更容易。
内容对象
OpenAPI 2.0 建立了以下复杂的关系：
- 声明响应媒体类型的位置
- 定义响应模式和示例的位置
可以在全局范围内定义多个响应媒体类型，但可以在操作级别可选地覆盖它们。但是，这允许为每个响应对象定义一个模式，尽管可以按媒体类型定义示例，或者每个模式一个。这使得难以为不同的媒体类型定义不同的模式，以及为不同的响应对象使用不同的媒体类型。
为了解决这个问题，内容对象引入了响应对象、媒体类型和模式之间简单的关系。每个响应对象都包含一个内容类型对象，用于每个支持的媒体类型。每个内容类型对象都有一个模式和一个用于该媒体类型的示例数组。
该内容对象也用于请求主体，并以相同的方式描述传入的有效负载。这具有神奇的效果，即消除了对produces和consumes数组的需求。关于是否也利用内容对象来描述复杂的 URL 参数和响应标头值的讨论仍在进行中。
这些更改导致路径项具有以下结构
Cookie 参数
虽然 TDC 成员一致同意，使用 Cookie 传递参数不是最佳实践，但仍有足够多的人表示希望描述现有的基于 Cookie 的 API，因此需要包含一个新的参数类型。
在下一篇文章中，我们将介绍要支持的新交互模式以及一些计划对有效负载描述进行的更改。