定义
版本 3.0.0
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.
This document is licensed under The Apache License, Version 2.0.
介绍
OpenAPI 规范(OAS),是定义一个标准的、与具体编程语言无关的RESTful API的规范。OpenAPI 规范使得人类和计算机都能在“不接触任何程序源代码和文档、不监控网络通信”的情况下理解一个服务的作用。如果您在定义您的 API 时做的很好,那么使用 API 的人就能非常轻松地理解您提供的 API 并与之交互了。
如果您遵循 OpenAPI 规范来定义您的 API,那么您就可以用文档生成工具来展示您的 API,用代码生成工具来自动生成各种编程语言的服务器端和客户端的代码,用自动测试工具进行测试等等。
目录
术语定义
开放API文档
一(或多)份用来定义或描述一个API的文档。
路径模板
路径模板指用大括号标记来标记一段URL作为可替换的路径参数。
媒体类型
媒体类型定义分散于多处。 媒体类型定义应当符合RFC6838。
以下是一些媒体类型定义的示例:
HTTP状态码
HTTP状态码被用来表示一次请求的被执行状态。 RFC7231定义了有效的状态码,可以在IANA Status Code Registry找到已经被注册的状态码的列表。
规范
版本
开放API规范使用符合语义化版本 2.0.0(semver)规范的版本号。
语义化版本的主版本号
、次版本号
部分(比如3.0
)应当被用来标记开放API规范的特性变动。通常 .修订号
版本被用来表示本文档文档的错误修正而不是特性变动。支持开放API规范3.0的工具应该兼容所有3.0.*的版本,工具不应当关注修订版本号,比如3.0.0
和3.0.1
对它来说应该没有任何区别。
此后开放API规范的相同主版本号下更高次要版本的发布不应当对面向低于此次要版本号开发的工具的造成干扰。因此3.1.0
版本的规范应当可以在面向3.0.0
版本规范开发的工具内使用。
任何兼容开放API规范 3.*.* 的文档应当包含一个openapi
字段用来表明它使用的规范的语义化版本。
格式
一份遵从开放API规范的文档是一个自包含的JSON对象,可以使用JSON或YAML格式编写。
比如一个字段有一组值,用JSON格式表示为:
规范内的所有字段名都是小写。
字段分为两种:固定字段和模式字段。固定字段的字段名是确定的,模式字段的字段名需要符合一定的模式。
如果一个对象里有模式字段,那么在这个对象里的模式字段的名字不能有重复的。
为了保留在 YAML 和 JSON 格式之间转换的能力,推荐使用1.2版本的YAML格式,而且还需要符合以下限制:
Tags 必须被限制在JSON Schema ruleset允许的范围内。
Keys 必须是YAML Failsafe schema ruleset规范定义的纯字符串。
注意: 虽然API文档是使用 YAML 或 JSON 格式书写的,但是API的请求体和响应体或者其他内容可以是任何格式。
文档结构
一份 OpenAPI 文档可以是单个文件也可以被拆分为多个文件, 连接的部分由用户自行决定。在后一种情形下,必须如 JSON Schema 中定义的那样使用 $ref
字段来相互引用。
推荐将根开放API文档命名为openapi.json
或 openapi.yaml
。
数据类型
在 OAS 中的原始数据类型是基于 JSON Schema Specification Wright Draft 00 所支持的类型。注意 integer
也作为一个被支持的类型并被定义为不包含小数或指数部分的 JSON 数字。 null
不是一个被支持的类型 (查看 nullable
来获得替代解决方案)。 Models 使用 Schema Object 定义,这是一个 JSON Schema Specification Wright Draft 00 的扩展。
原始类型可以有一个可选的修饰属性:format
。 OAS 使用多个已知的格式来丰富类型定义。尽管如此,为了文档的需要,format
属性被设计为一个 string
类型的开放属性值,可以包含任意值。比如 "email"
, "uuid"
等未被此规范定义的格式也可以被使用。没有被定义的 format
属性类型遵从 JSON Schema 中的类型定义。无法识别某个 format
值的工具应该回退到 type
值,就像 format
未被指定一样。
被 OAS 定义的格式:
通用名 | 备注 | ||
integer |
|
| 32 位有符号 |
long |
|
| 64 位有符号 |
float |
|
| |
double |
|
| |
string |
| ||
byte |
|
| base64 编码的支付 |
binary |
|
| 任意 8进制序列 |
boolean |
| ||
date |
|
| 定义于 |
dateTime |
|
| 定义于 |
password |
|
| 告知输入界面不应该明文显示输入信息。 |
富文本格式
整个规范中的 description
字段被标记为支持 CommonMark markdown 格式。 OpenAPI 相关的工具在支持 CommonMark 0.27 中描述的富文本格式方面至少需要支持渲染 markerdown。相关工具为了安全考虑可以选择忽略某些 CommonMark 特性。
URL的相对引用
除非明确指定,所有 URL 类型的属性值都可以是相对地址,就如 RFC3986 中定义的那样以 Server Object
作为 Base URI。
在 $ref
中的相对引用以 JSON Reference 为依据,以当前文档的 URL 作为 base URI. 同时参考 Reference Object。
结构
在接下来的叙述中,如果一个字段没有被明确的标记为 必选 或者被描述为 必须 或 应当,那么可以认为它是一个 可选 字段
OpenAPI 对象
这是OpenAPI document的根文档对象。
固定字段
字段名 | 类型 | 描述 |
openapi |
| 必选. 这个字符串必须是开放API规范版本号提到的符合语义化版本号规范的版本号。 |
info | 必选。此字段提供API相关的元数据。相关工具可能需要这个字段。 | |
servers | ||
paths | 必选。对所提供的API有效的路径和操作。 | |
components | 一个包含多种结构的元素。 | |
security | 声明API使用的安全机制。The list of values includes alternative security requirement objects that can be used. 认证一个请求时仅允许使用一种安全机制。单独的操作可以覆盖这里的定义。 | |
tags | [Tag 对象] | 提供更多元数据的一系列标签,标签的顺序可以被转换工具用来决定API的顺序。不是所有被Operation 对象用到的标签都必须被声明。没有被声明的标签可能被工具按自己的逻辑任意整理,每个标签名都应该是唯一的。 |
externalDocs | 附加的文档。这个对象可能会被规范扩展扩展。 |
Info 对象
这个对象提供API的元数据。如果客户端需要时可能会用到这些元数据,而且可能会被呈现在编辑工具或者文档生成工具中。
固定字段
字段名 | 类型 | 描述 |
title |
| 必选. 应用的名称。 |
description |
| 对应用的简短描述。 CommonMark syntax 可以被用来表示富文本呈现。 |
termsOfService |
| 指向服务条款的URL地址,必须是URL地址格式。 |
contact | 所开放的API的联系人信息。 | |
license | 所开放的API的证书信息。 | |
version |
| 必选. API文档的版本信息(注意:这个版本和开放API规范版本没有任何关系)。 |
Info 对象示例
Contact 对象
所公开的API的联系人信息
固定字段
字段名 | 类型 | 描述 |
name |
| 人或组织的名称。 |
url |
| 指向联系人信息的URL地址,必须是URL地址格式。 |
| 人或组织的email地址,必须是email地址格式。 |
这个对象可能会被规范扩展扩展。
Contact 对象示例
License 对象
公开API的证书信息。
固定字段
字段名 | 类型 | 描述 |
name |
| 必选. API的证书名。 |
url |
| 指向API所使用的证书的URL地址,必须是URL地址格式。 |
这个对象可能会被规范扩展扩展。
License 对象示例
Server 对象
表示一个服务器的对象。
固定字段
字段名 | 类型 | 描述 |
url |
| 必选. 指向目标主机的URL地址。这个URL地址支持服务器变量而且可能是相对路径,表示主机路径是相对于本文档所在的路径。当一个变量被命名为类似 |
description |
| 一个可选的字符串,用来描述此URL地址。CommonMark syntax可以被用来呈现富文本格式. |
variables | Map[ | 一组变量和值的映射,这些值被用来替换服务器URL地址内的模板参数。 |
这个对象可能会被规范扩展扩展。
Server 对象示例
单个服务器可以这样描述:
以下内容表示的是有多个服务器时应该如何描述,比如OpenAPI 对象的servers
:
以下内容展示了如何使用变量来配置服务器:
Server Variable 对象
表示可用于服务器URL地址模板变量替换的对象。
固定字段
字段名 | 类型 | 描述 |
enum | [ | 一组可枚举字符串值,当可替换选项只能设置为固定的某些值时使用。 |
default |
| 必选. 当可替换的值没有被使用者指定时使用的默认值。不像Schema Object's的 |
description |
| 对服务器变量的可选的描述。CommonMark syntax可以被用来呈现富文本格式. |
这个对象可能会被规范扩展扩展。
Components 对象
包含开放API规范固定的各种可重用组件。当没有被其他对象引用时,在这里定义定义的组件不会产生任何效果。
固定字段
字段名 | 类型 | 描述 |
schemas | Map[ | 定义可重用的 Schema 对象 的对象。 |
responses | Map[ | 定义可重用的 Response 对象 的对象。 |
parameters | Map[ | 定义可重用的 Parameter 对象 的对象。 |
examples | Map[ | 定义可重用的 Example 对象 的对象。 |
requestBodies | Map[ | 定义可重用的 Request Body 对象 的对象。 |
headers | Map[ | 定义可重用的 Header 对象 的对象。 |
securitySchemes | Map[ | 定义可重用的 Security Scheme 对象 的对象。 |
links | Map[ | 定义可重用的 Link 对象 的对象。 |
callbacks | Map[ | 定义可重用的 Callback 对象 的对象。 |
这个对象可能会被 规范扩展 扩展。
上面定义的所有固定字段的值都是对象,对象包含的key的命名必须满足正则表达式: ^[a-zA-Z0-9\.\-_]+$
。
字段名示例:
Components 对象示例
Paths 对象
定义各个的端点和操作的相对路径。这里指定的路径会和 Server 对象
内指定的URL地址组成完整的URL地址,路径可以为空,这依赖于 ACL constraints 的设置。
模式字段
字段名模式 | 类型 | 描述 |
/{path} | 到各个端点的相对路径,路径必须以 |
这个对象可能会被规范扩展扩展。
路径模板匹配
假设有以下路径,明确定义的路径 /pets/mine
会被优先匹配:
以下路径被认为是等价的而且是无效的:
以下路径会产生歧义:
Paths 对象示例
Path Item 对象
描述对一个路径可执行的有效操作。依赖与 ACL constraints 的设置,一个Path Item可以是一个空对象,文档的读者仍然可以看到这个路径,但是他们将无法了解到对这个路径可用的任何操作和参数。
固定字段
字段名 | 类型 | 描述 |
$ref |
| 指定对此路径的外部定义的引用,引用的格式必须符合 Path Item 对象 的格式,如果引用的外部定义和此对象内的其他定义有冲突,该如何处理冲突尚未被定义。 |
summary |
| 一个可选的简要总结字符串,用来描述此路径内包含的所有操作。 |
description |
| 一个可选的详细说明字符串,用于描述此路径包含的所有操作。 CommonMark syntax可以被用来呈现富文本格式. |
get | 定义适用于此路径的 GET 操作。 | |
put | 定义适用于此路径的 PUT 操作。 | |
post | 定义适用于此路径的 POST 操作. | |
delete | 定义适用于此路径的 DELETE 操作。 | |
options | 定义适用于此路径的 OPTIONS 操作。 | |
head | 定义适用于此路径的 HEAD 操作。 | |
patch | 定义适用于此路径的 PATCH 操作。 | |
trace | 定义适用于此路径的 TRACE 操作。 | |
servers | 一个可用于此路径所有操作的替代根 | |
parameters | 一个可用于此路径下所有操作的参数的列表。这些参数可以被具体的操作定义覆盖,但是不能被移除。这个列表禁止包含重复的参数,一个唯一的参数名由 name 和 location 的组合来定义。这个列表可以使用 Reference 格式引用定义在 OpenAPI 对象 components/parameters 内的参数。 |
这个对象可能会被规范扩展扩展。
Path Item 对象示例
Operation Object
描述对路径的某个操作。
固定字段
字段名 | 类型 | 描述 |
tags | [ | 用于控制API文档的标签列表,标签可以用于在逻辑上分组对资源的操作或作为其它用途的先决条件。 |
summary |
| 对此操作行为的简短描述。 |
description |
| 对此操作行为的详细解释。CommonMark syntax可以被用来呈现富文本格式. |
externalDocs | 附加的外部文档。 | |
operationId |
| 用于标识此操作的唯一字符串,这个id在此API内包含的所有操作中必须是唯一的。相关的工具和库可能会使用此operationId来唯一的标识一个操作,因此推荐在命名时符合一般的编程命名习惯。 |
parameters | 定义可用于此操作的参数列表,如果一个同名的参数已经存在于 Path Item,那么这里的定义会覆盖它但是不能移除上面的定义。这个列表不允许包含重复的参数,参数的唯一性由 name 和 location 的组合来确定。这个列表可以使用 Reference 对象 来连接定义于 OpenAPI 对象 components/parameters 的参数。 | |
requestBody | 可用于此操作的请求体。 | |
responses | 必选. 定义执行此操作后的可能的响应值列表。 | |
callbacks | Map[ | 一组相对于父操作的可能出现的回调映射,A map of possible out-of band callbacks related to the parent operation. 映射中的每一个键都唯一的映射一个 Callback 对象, that describes a request that may be initiated by the API provider and the expected responses. The key value used to identify the callback object is an expression, evaluated at runtime, that identifies a URL to use for the callback operation. |
deprecated |
| 声明此操作已经被废弃,使用者应该尽量避免使用此操作,默认的值是 |
security | 声明那种安全机制可用于此操作。这个列表可以包含多种可用于此操作的安全需求对象,但是在认证一个请求时应该仅使用其中一种。这里的定义会覆盖任何在顶层 | |
servers | 一个可用于此操作的额外的 |
这个对象可能会被规范扩展扩展。
Operation 对象示例
External Documentation 对象
允许引用外部资源来扩展文档。
固定字段
字段名 | 类型 | 描述 |
description |
| 对引用的外部文档的简短描述。CommonMark syntax可以被用来呈现富文本格式. |
url |
| 必选. 外部文档的URL地址,这个值必须是URL地址格式。 |
这个对象可能会被规范扩展扩展。
External Documentation 对象示例
Parameter Object
描述一个操作参数。
一个参数的唯一性由 name 和 location 的组合来确定。
参数位置
有4种可能的参数位置值可用于in
字段:
path - 与 Path Templating 一起使用,当参数的值是URL操作路径的一部分时可以使用,但是不包含主机地址或基础路径。比如在路径
/items/{itemId}
中,路径参数是itemId
。query - 追加在URL地址之后的参数,比如
/items?id=###
中,查询参数是id
。header - 请求中使用的自定义请求头,注意在 RFC7230 中规定,请求头的命名是不区分大小写的。
cookie - 用于传递特定的cookie值。
固定字段
字段名 | 类型 | 描述 |
name |
| 必选. 参数的名称。参数名是区分大小写。 |
in |
| 必选. 参数的位置,可能的值有 "query", "header", "path" 或 "cookie"。 |
description |
| 对此参数的简要描述,这里可以包含使用示例。CommonMark syntax可以被用来呈现富文本格式. |
required |
| 标明此参数是否是必选参数。如果 参数位置 的值是 |
deprecated |
| 标明一个参数是被弃用的而且应该尽快移除对它的使用。 |
allowEmptyValue |
| 设置是否允许传递空参数,这只在参数值为 |
序列化参数的规则有两种。 对于简单的场景, schema
和 style
可以用于描述参数的结构和语法。
字段名 | 类型 | 描述 |
style |
| 描述根据参数值类型的不同如何序列化参数。默认值为(基于 |
explode |
| 当这个值为 |
allowReserved |
| 决定此参数的值是否允许不使用%号编码使用定义于 RFC3986内的保留字符 |
schema | 定义适用于此参数的类型结构。 | |
example | Any | 不同媒体类型的示例,示例应该符合响应的结构的编码属性。各个 |
examples | Map[ | 不同媒体类型的示例。每个示例应该包含一个对应于指定编码格式的格式正确的值,这个 |
对于更复杂的场景,content
属性可以定义参数的媒体类型和概要。一个参数必须且只能包含schema
和content
属性中的一个。当example
或examples
字段提供了schema
对象时,示例必须遵照参数的序列化策略。
字段名 | 类型 | 描述 |
content | Map[ | 一个定义参数如何呈现的键值对映射。键是媒体类型,值是对应媒体类型的示例数据,此键值对只能包含一组键值对。 |
样式值
已经定义好了一组style
类型用于支持常见的通用的简单参数序列化。
|
| 描述 | ||
matrix |
|
| Path 样式的参数,参见 RFC6570 | |
label |
|
| Label 样式的参数,参见 RFC6570 | |
form |
|
| Form 样式的参数,参见 RFC6570. 此选项替换定义于OpenAPI 2.0中 | |
simple |
|
| Simple 样式的参数,参见 RFC6570. 此选项替换定义于OpenAPI 2.0 中 | |
spaceDelimited |
|
| 空格分隔的数组值。此选项替换定义于OpenAPI 2.0 中 | |
pipeDelimited |
|
| 管道符` |
|
deepObject |
|
| 提供一种简单的方法来表示参数中的嵌套对象值. |
Style 示例
建设一个参数名为color
包含如下之一的值:
下面这个表展示了各个不同类型值之间的例子。
|
|
|
|
| ||
matrix | false | ;color | ;color=blue | ;color=blue,black,brown | ;color=R,100,G,200,B,150 | |
matrix | true | ;color | ;color=blue | ;color=blue;color=black;color=brown | ;R=100;G=200;B=150 | |
label | false | . | .blue | .blue.black.brown | .R.100.G.200.B.150 | |
label | true | . | .blue | .blue.black.brown | .R=100.G=200.B=150 | |
form | false | color= | color=blue | color=blue,black,brown | color=R,100,G,200,B,150 | |
form | true | color= | color=blue | color=blue&color=black&color=brown | R=100&G=200&B=150 | |
simple | false | n/a | blue | blue,black,brown | R,100,G,200,B,150 | |
simple | true | n/a | blue | blue,black,brown | R=100,G=200,B=150 | |
spaceDelimited | false | n/a | n/a | blue%20black%20brown | R%20100%20G%20200%20B%20150 | |
pipeDelimited | false | n/a | n/a | blue|black|brown | R|100|G|200 | G|150 |
deepObject | true | n/a | n/a | n/a | color[R]=100&color[G]=200&color[B]=150 |
这个对象可能会被规范扩展扩展。
Parameter 对象示例
一个值数组,数组元素为64位整数值的请求头参数:
一个值类型为字符串的路径参数:
一个值类型为字符串的可选查询参数,允许通过通过重复参数来传递多个值:
一个任意格式的查询参数,允许使用指定类型的未定义参数:
使用content
定义序列化方法的复杂参数:
Request Body Object
定义请求体。
固定字段
字段名 | 类型 | 描述 |
description |
| 对请求体的简要描述,可以包含使用示例,CommonMark syntax可以被用来呈现富文本格式. |
content | Map[ | 必选. 请求体的内容。请求体的属性key是一个媒体类型或者媒体类型范围,值是对应媒体类型的示例数据。对于能匹配多个key的请求,定义更明确的请求会更优先被匹配。比如 |
required |
| 指定请求体是不是应该被包含在请求中,默认值是 |
这个对象可能会被规范扩展扩展。
Request Body 示例
一个引用了模型定义的请求体。
请求体是一个字符串的数组:
Media Type 对象
每种媒体类型对象都有相应的结构和示例来描述它。
固定字段
字段名 | 类型 | 描述 |
schema | 定义此媒体类型的结构。 | |
example | Any | 媒体类型的示例。示例对象应该符合此媒体类型的格式, 这里指定的 |
examples | Map[ | 媒体类型的示例,每个媒体对象的值都应该匹配它对应的媒体类型的格式。 The |
encoding | Map[ | 属性名与编码信息的映射。每个属性名必须存在于 |
这个对象可能会被规范扩展扩展。
Media Type 示例
对文件上传的考虑
相对于2.0的规范,file
内容的上传与下载在开放API规范与其他类型一样使用相同的语法来描述。 特别的是:
这些示例同时适用于文件上传和下载。
一个使用POST
操作提交文件的requestBody
看起来像下面这样:
此外,可以指定明确的媒体类型:
为了同时上传多个文件,必须指定multipart
媒体类型:
x-www-form-urlencoded 请求体的支持
可以使用下面定义的格式来提交form url编码RFC1866的内容:
在这个示例中,在内容被传送到服务器之前,requestBody
中的内容必须使用RFC1866中定义的方式字符串化。此外address
字段的复杂对象将会被字符串化。
当使用application/x-www-form-urlencoded
格式传送复杂对象时,默认的序列化策略在Encoding Object
的style
属性中定义为form
.
对multipart内容的特别思考
使用multipart/form-data
作为Content-Type
来传送请求体是很常见的做法。相对于2.0版本的规范,当定义multipart
内容的输入参数时必须指定schema
属性。这不但支持复杂的结构而且支持多文件上传机制。
当使用multipart
类型是,可以使用boundaries来分隔传送的内容,因此multipart
定义了以下默认的Content-Type
:
如果属性是一个原始值或者是一个原始值的数组,那么默认的Content-Type是
text/plain
如果属性是复杂对象或者复杂对象的数组,那么默认的Content-Type是
application/json
如果属性是
type: string
与format: binary
或format: base64
(也就是文件对象)的组合,那么默认的Content-Type是application/octet-stream
示例:
这里介绍一下用来控制序列化multipart
请求体的encoding
属性,这个属性只适用于multipart
和application/x-www-form-urlencoded
类型的请求体。
Encoding 对象
一个编码定义仅适用于一个结构属性。
固定字段
字段名 | 类型 | 描述 |
contentType |
| 对具体属性的 Content-Type的编码。默认值取决于属性的类型: |
headers | Map[ | 提供附加信息的请求头键值对映射。比如 |
style |
| 描述一个属性根据它的类型将会被如何序列化。查看Parameter 对象的 |
explode |
| 当这个值为true时,类型为 |
allowReserved |
| 决定此参数的值是否允许不使用%号编码使用定义于 RFC3986内的保留字符 |
这个对象可能会被规范扩展扩展。
Encoding 对象示例
Responses 对象
描述一个操作可能发生的响应的响应码与响应包含的响应体的对象。
一份API文档不必包含所有可能响应码,因为有些状态码无法提前预知。尽管如此,一份文档还是应当包含所有成功的响应和任何已知的错误响应。
default
字段可以用来标记一个响应适用于其他未被规范明确定义的HTTP响应码的默认响应。
一个Responses 对象
必须至少包含一个响应码,而且是成功的响应。
固定字段
字段名 | 类型 | 描述 |
default | 用于描述未被明确声明的HTTP响应码的响应的文档。使用这个字段来覆盖未声明的响应。一个 Reference 对象 可以链接定义于 OpenAPI 对象 components/responses 区域的响应对象。 |
模式字段
字段名模式 | 类型 | 描述 |
任何 HTTP status code 都可以被用作属性名, 但是每一个状态码只能使用一次,用于描述此状态码的响应。一个 Reference 对象 可以链接定义于 OpenAPI 对象 components/responses 区域的响应对象。这个字段名必须包含在双引号中 (例如 "200") 以兼容 JSON 和 YAML。这个字段可以包含大写的通配字符 |
这个对象可能会被规范扩展扩展。
Responses 对象示例
一个代表成功操作的 200 响应和一个代表其他操作状态的默认响应(暗示是一个错误):
Response对象
描述单个API操作的响应,包括设计时间、基于不同响应也包括到相应操作的静态links
固定字段
字段名 | 类型 | 描述 |
description |
| 必选. 对响应的简短描述。CommonMark syntax可以被用来呈现富文本格式. |
headers | Map[ | 映射HTTP头名称到其定义。RFC7230 规定了HTTP头名称不区分大小写。如果一个响应头使用 |
content | Map[ | 一个包含描述预期响应负载的映射。使用 media type 或 media type range 作为键,以响应的描述作为值。当一个响应匹配多个键时,只有最明确的键才适用。比如:text/plain 会覆盖 text/* |
links | Map[ | A map of operations links that can be followed from the response. The key of the map is a short name for the link, following the naming constraints of the names for Component Objects. |
这个对象可能会被规范扩展扩展。
Response 对象示例s
一个包含复杂类型的数组格式的响应:
字符串类型的响应:
带HTTP头的普通文本类型的响应:
没有返回值的响应:
Callback 对象
A map of possible out-of band callbacks related to the parent operation. 映射中的每个值都是一个描述一组可能会被API提供者发起的请求和相应的响应的 Path Item Object 。用以标识回调对象的键是一个表达式,表达式会在运行时被计算,得到的值作为回调操作的URL。
模式字段
字段名模式 | 类型 | 描述 |
{expression} | 一个用于定义回调请求和响应的 Path Item Object。 A complete example is available. |
这个对象可能会被规范扩展扩展。
Key Expression
用于标识 Path Item Object 的键是一个 runtime expression,此表达式会在运行时的HTTP请求/响应上下文中被计算,计算结果用于表示回调请求的URL。 一个简单的例子是 $request.body#/url
。 However, using a runtime expression the complete HTTP message can be accessed. This includes accessing any part of a body that a JSON Pointer RFC6901 can reference.
比如有如下 HTTP 请求:
下方示例展示了各种表达式是如何被计算,这里假设回调操作有一个名为 eventType
的路径参数和一个名为 queryUrl
的查询参数。
Expression | Value |
$url | |
$method | POST |
$request.path.eventType | myevent |
$request.query.queryUrl | |
$request.header.content-Type | application/json |
$request.body#/failedUrl | |
$request.body#/successUrls/2 | |
$response.header.Location |
Callback 对象示例
如下示例展示了一个通过请求体内的 id
和 email
属性指定的URL的回调。
Example 对象
固定字段
字段名 | 类型 | 描述 |
summary |
| example 的简要描述。 |
description |
| example 的详细描述。CommonMark syntax可以被用来呈现富文本格式. |
value | Any | 嵌入的字面量 example。 |
externalValue |
| 指向字面 exmaple 的一个 URL。这提供了引用无法被包含在 JSON 或 YAML 文档中的 example。 |
这个对象可能会被规范扩展扩展。
In all cases, the example value is expected to be compatible with the type schema of its associated value. Tooling implementations MAY choose to validate compatibility automatically, and reject the example value(s) if incompatible.
Example 对象示例
Link 对象
The Link 对象
represents a possible design-time link for a response. The presence of a link does not guarantee the caller's ability to successfully invoke it, rather it provides a known relationship and traversal mechanism between responses and other operations.
Unlike dynamic links (i.e. links provided in the response payload), the OAS linking mechanism does not require link information in the runtime response.
For computing links, and providing instructions to execute them, a runtime expression is used for accessing values in an operation and using them as parameters while invoking the linked operation.
固定字段
字段名 | Type | 描述 |
operationRef |
| A relative or absolute reference to an OAS operation. This field is mutually exclusive of the |
operationId |
| The name of an existing, resolvable OAS operation, as defined with a unique |
parameters | Map[ | A map representing parameters to pass to an operation as specified with |
requestBody | Any | {expression} | A literal value or {expression} to use as a request body when calling the target operation. |
description |
| A description of the link. CommonMark syntax可以被用来呈现富文本格式. |
server | A server object to be used by the target operation. |
这个对象可能会被规范扩展扩展。
A linked operation MUST be identified using either an operationRef
or operationId
. In the case of an operationId
, it MUST be unique and resolved in the scope of the OAS document. Because of the potential for name clashes, the operationRef
syntax is preferred for specifications with external references.
Examples
Computing a link from a request operation where the $request.path.id
is used to pass a request parameter to the linked operation.
When a runtime expression fails to evaluate, no parameter value is passed to the target operation.
Values from the response body can be used to drive a linked operation.
Clients follow all links at their discretion. Neither permissions, nor the capability to make a successful call to that link, is guaranteed solely by the existence of a relationship.
OperationRef Examples
As references to operationId
MAY NOT be possible (the operationId
is an optional value), references MAY also be made through a relative operationRef
:
or an absolute operationRef
:
Note that in the use of operationRef
, the escaped forward-slash is necessary when using JSON references.
Runtime Expressions
Runtime expressions allow defining values based on information that will only be available within the HTTP message in an actual API call. This mechanism is used by Link Objects and Callback Objects.
The runtime expression is defined by the following ABNF syntax
The name
identifier is case-sensitive, whereas token
is not.
The table below provides examples of runtime expressions and examples of their use in a value:
Examples
Source Location | example expression | notes |
HTTP Method |
| The allowable values for the |
Requested media type |
| |
Request parameter |
| Request parameters MUST be declared in the |
Request body property |
| In operations which accept payloads, references may be made to portions of the |
Request URL |
| |
Response value |
| In operations which return payloads, references may be made to portions of the response body or the entire body. |
Response header |
| Single header values only are available |
Runtime expressions preserve the type of the referenced value. Expressions can be embedded into string values by surrounding the expression with {}
curly braces.
Header 对象
Header 对象除了以下改动之外与 Parameter 对象 一致:
name
不能被指定,它在相应的headers
映射中被指定。in
不能被指定,它隐含在header
中。所有被 location 影响的特性必须适合
header
中的一个 location,(比如style
)。
Header 对象示例
一个类型为 integer
的简单 header:
Tag Object
Adds metadata to a single tag that is used by the Operation Object. It is not mandatory to have a Tag Object per tag defined in the Operation Object instances.
固定字段
字段名 | 类型 | 描述 |
name |
| 必选. The name of the tag. |
description |
| A short description for the tag. CommonMark syntax可以被用来呈现富文本格式. |
externalDocs | Additional external documentation for this tag. |
这个对象可能会被规范扩展扩展。
Tag 对象示例
Examples Object
In an example
, a JSON Reference MAY be used, with the explicit restriction that examples having a JSON format with object named $ref
are not allowed. Therefore, that example
, structurally, can be either a string primitive or an object, similar to additionalProperties
.
In all cases, the payload is expected to be compatible with the type schema for the associated value. Tooling implementations MAY choose to validate compatibility automatically, and reject the example value(s) if they are incompatible.
Reference 对象
一个允许引用规范内部的其他部分或外部规范的对象。
Reference Object 定义于 JSON Reference 且遵循相同的结构、行为和规则。
For this specification, reference resolution is accomplished as defined by the JSON Reference specification and not by the JSON Schema specification.
固定字段
字段名 | 类型 | 描述 |
$ref |
| 必选. 引用字符串。 |
此对象不能被扩展,任何附加的属性将会被忽略。
Reference 对象示例
关联外部文档示例
关联外部文档的一部分
Schema Object
Schema Object 用于定义输入和输出的数据类型。这些类型可以是对象,但也可以是原始值和数组。这个对象是 JSON Schema Specification Wright Draft 00 扩展后的子集.
关于property的的更多信息请查看 JSON Schema Core 和 JSON Schema Validation。除非另有说明,否则 properties 定义遵循JSON Schema。
Properties
以下 properties 是直接从 JSON Schema 提取出来的,而且遵循同样的规范:
title
multipleOf
maximum
exclusiveMaximum
minimum
exclusiveMinimum
maxLength
minLength
pattern (This string SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect)
maxItems
minItems
uniqueItems
maxProperties
minProperties
required
enum
以下 properties 是从 JSON Schema 提取出来的,但是做了一些调整以适应 OpenAPI Specification。
type - 值必须是一个字符串,不支持以数组形式定义多个值。
allOf - Inline 或 referenced 的 schema 必须是一个 Schema Object 且不是一个标准的 JSON Schema。
oneOf - Inline 或 referenced 的 schema 必须是一个 Schema Object 且不是一个标准的 JSON Schema。
anyOf - Inline 或 referenced 的 schema 必须是一个 Schema Object 且不是一个标准的 JSON Schema。
not - Inline 或 referenced 的 schema 必须是一个 Schema Object 且不是一个标准的 JSON Schema。
items - 值必须是一个对象且不是一个数组。Inline 或 referenced 的 schema 必须是一个 Schema Object且不是一个标准的 JSON Schem。.
items
必须存在如果type
的值是array
。properties - Property 定义必须是一个 Schema Object 且不是一个标准的 JSON Schema (inline 或 referenced).
additionalProperties - 值可以是 boolean 或 object. Inline 或 referenced schema 必须是一个 Schema Object 且不是一个标准的 JSON Schema。
description - CommonMark syntax可以被用来呈现富文本格式.
format - 查看 Data Type Formats 以深入了解细节。在依靠 JSON Schema 定义的格式的同时,OAS 额外提供了一些预定义的格式。
default - The default value represents what would be assumed by the consumer of the input as the value of the schema if one is not provided. 不同于 JSON Schema,这个值必须符合定义与相同级别的 Schema Object 中定义的类型,比如
type
是string
,那么default
可以是"foo"
但不能是1
。
另外,任何可以使用 Schema Object 的地方也可以使用 Reference Object 替代。这允许引用一个定义而避免重复定义。
未在此处提及的 JSON Schema 规范中定义的其他属性将严格的不被支持。
Other than the JSON Schema subset fields, 以下字段可能会被用于后续的 schema documentation:
固定字段
字段名 | 类型 | 描述 |
nullable |
| 对于定义的schema,允许发送 |
discriminator | Adds support for polymorphism. The discriminator is an object name that is used to differentiate between other schemas which may satisfy the payload description. See Composition and Inheritance for more details. | |
readOnly |
| 仅与 Schema |
writeOnly |
| 仅与 Schema |
xml | 这只能用于 properties schemas,在 root schemas 中没有效果。Adds additional metadata to describe the XML representation of this property. | |
externalDocs | 此 schema 附加的外部文档。 | |
example | Any | 一个用于示范此 schema实例的示例,可以是任意格式。为了表达无法用 JSON 或 YAML 格式呈现的示例,可以使用 string 类型的值,且在必要的地方需要使用字符转义。 |
deprecated |
| 表示一个 schema 是废弃的,应该逐渐被放弃使用。默认值是 |
这个对象可能会被规范扩展扩展。
Composition and Inheritance (Polymorphism)
The OpenAPI Specification allows combining and extending model definitions using the allOf
property of JSON Schema, in effect offering model composition. allOf
takes an array of object definitions that are validated independently but together compose a single object.
While composition offers model extensibility, it does not imply a hierarchy between the models. To support polymorphism, the OpenAPI Specification adds the discriminator
field. When used, the discriminator
will be the name of the property that decides which schema definition validates the structure of the model. As such, the discriminator
field MUST be a required field. There are are two ways to define the value of a discriminator for an inheriting instance.
Use the schema name.
Override the schema name by overriding the property with a new value. If a new value exists, this takes precedence over the schema name.
As such, inline schema definitions, which do not have a given id, cannot be used in polymorphism.
XML Modeling
The xml property allows extra definitions when translating the JSON definition to XML. The XML Object contains additional information about the available options.
Schema 对象示例s
Primitive Sample
Simple Model
Model with Map/Dictionary Properties
For a simple string to string mapping:
For a string to model mapping:
Model with Example
Models with Composition
Models with Polymorphism Support
Discriminator 对象
当一个 request bodies 或 response payloads 可以是多种 schemas 时,可以使用一个 discriminator
对象来帮助序列化、反序列化和校验。 The discriminator is a specific object in a schema which is used to inform the consumer of the specification of an alternative schema based on the value associated with it.
当使用 discriminator 时,inline schemas 不会被考虑。
固定字段
字段名 | 类型 | 描述 |
propertyName |
| 必选. 在 payload 中表示 discriminator 值的属性的名称。 |
mapping | Map[ | 一个映射 payload 中的值和 schema 名称或引用的对象。 |
discriminator 属性仅在与 oneOf
, anyOf
, allOf
这几个复合关键字之一一起使用时才合法.
在 OAS 3.0 中,一个 response payload 仅可以使用一种类型来描述:
也就是说 payload 必须 且只能满足 Cat
、Dog
或 Lizzard
schemas 中的一个。 In this case, a discriminator MAY act as a "hint" to shortcut validation and selection of the matching schema which may be a costly operation, depending on the complexity of the schema. We can then describe exactly which field tells us which schema to use:
The expectation now is that a property with name pet_type
MUST be present in the response payload, and the value will correspond to the name of a schema defined in the OAS document. Thus the response payload:
Will indicate that the Cat
schema be used in conjunction with this payload.
In scenarios where the value of the discriminator field does not match the schema name or implicit mapping is not possible, an optional mapping
definition MAY be used:
Here the discriminator value of dog
will map to the schema #/components/schemas/Dog
, rather than the default (implicit) value of Dog
. If the discriminator value does not match an implicit or explicit mapping, no schema can be determined and validation SHOULD fail. Mapping keys MUST be string values, but tooling MAY convert response values to strings for comparison.
When used in conjunction with the anyOf
construct, the use of the discriminator can avoid ambiguity where multiple schemas may satisfy a single payload.
In both the oneOf
and anyOf
use cases, all possible schemas MUST be listed explicitly. To avoid redundancy, the discriminator MAY be added to a parent schema definition, and all schemas comprising the parent schema in an allOf
construct may be used as an alternate schema.
For example:
a payload like this:
will indicate that the Cat
schema be used. Likewise this schema:
will map to Dog
because of the definition in the mappings
element.
XML 对象
一个为 XML 模型定义微调过的元数据对象。
当使用数组时,不会推测 XML 元素的名称(单数或复数形式),所以应该添加 name
属性来提供此信息。 查看展示此期望的示例。
固定字段
字段名 | 类型 | 描述 |
name |
| 替换用于描述元素/属性的结构特性的名称。当在 |
namespace |
| 命名空间定义的 URI。其值必须是绝对 URI。 |
prefix |
| 用于 name 的前缀。 |
attribute |
| 声明此特性定义会被转换为一个属性而不是一个元素。默认值是 |
wrapped |
| 只可被用于数组定义。表示数组是否被包裹(比如, |
这个对象可能会被规范扩展扩展。
XML 对象示例
XML 对象定义的示例被包括在一个 Schema 对象 的特性定义并带有一个样例 XML 来呈现它。
无 XML 元素
基础字符串属性:
基础字符串数组属性 (wrapped
默认是 false
):
XML 名称替换
XML 属性,前缀和命名空间
在此示例中展示了一个完整的模型定义。
XML 数组
改变元素的名称:
外部的 name
属性在 XML 上不产生效果:
尽管数组是被包裹的,如果没有明确定义一个名称,那么同样地名称会被用于内部和外部:
为了解决上面示例的命名问题,可以使用下面的定义:
Affecting both internal and external names:
如果我们改变外部的元素而保持内部的不变:
Security Scheme 对象
定义一个用于 operations 的 security scheme。被支持的 schemes 有 HTTP 认证,一个 API key(作为 header 或 query parameter),定义于RFC6749 的 Oauth2 常用流程(implicit、password、application 和 access code)和 OpenID Connect Discovery。
固定字段
字段名 | 类型 | Applies To | 描述 |
type |
| Any | 必选. security scheme 的类型。有效值包括 |
description |
| Any | 对 security scheme 的简短描述. CommonMark syntax可以被用来呈现富文本格式. |
name |
|
| 必选. 用于 header、 query 或 cookie 的参数名字。 |
in |
|
| 必选. API key 的位置。有效值包括 |
scheme |
|
| 必选. 用于 Authorization header as defined in RFC7235 的 HTTP Auahorization scheme 的名字. |
bearerFormat |
|
| 用于提示客户端所使用的bearer token的格式。Bearer token 通常通过一个authorization server生成,所以这个字段最主要的目的是用来记录这个信息。 |
flows |
| 必选. 一个包含所支持的 flow types 的配置信息的对象。 | |
openIdConnectUrl |
|
| 必选. 用于发现 OAuth2 配置值的OpenId Connect URL,必须是 URL 形式。 |
这个对象可能会被规范扩展扩展。
Security Scheme 对象示例
Basic Authentication Sample
API Key Sample
JWT Bearer Sample
Implicit OAuth2 Sample
OAuth Flows 对象
允许配置支持的 OAuth Flows。
固定字段
字段名 | 类型 | 描述 |
implicit | OAuth Implicit flow 的配置 | |
password | OAuth Resource Owner Password flow 的配置 | |
clientCredentials | OAuth Client Credentials flow 的配置。在 OpenAPI 2.0 中曾被称作 | |
authorizationCode | OAuth Authorization Code flow 的配置。在 OpenAPI 2.0 中曾被称作 |
这个对象可能会被规范扩展扩展。
OAuth Flow 对象
支持的 OAuth Flow 的配置详情。
固定字段
字段名 | 类型 | Applies To | 描述 |
authorizationUrl |
|
| 必选。用于此流程的 authorization URL。必须是 URL 形式。 |
tokenUrl |
|
| 必选。用于此流程的 token URL。必须是 URL 形式。 |
refreshUrl |
|
| 用于获取 refresh tokens 的 URL,必须是 URL 形式。 |
scopes | Map[ |
| 必选。可用于 OAuth2 security scheme 的 scope。scope 名称与其简短描述的映射。 |
这个对象可能会被规范扩展扩展。
OAuth Flow 对象示例s
Security Requirement 对象
列出执行此 operation 所需的 security schemes。每个属性的名字都必须与 Components Object 中 Security Schemes 声明的 security scheme 相符。
包含多个 schemes 的 Security Requirement 对象中的所有 scheme 都必须要满足授权请求。这便能够支持需要使用多个 query parameters 或 HTTP headers 来传递安全信息的情景。
当When a list of Security Requirement Objects is defined on the Open API 对象 或 [Operation 对象] (#operationObject) 包含一组 Security Requirement 对象时,请求只需要满足其中一个即可。
模式字段
字段名模式 | 类型 | 描述 |
{name} | [ | 每个名称都必须对应于 Components 对象 下的 Security Schemes 的一个 security scheme。如果此 security scheme 是 |
Security Requirement 对象示例
Non-OAuth2 Security Requirement
OAuth2 Security Requirement
规范扩展
尽管 OpenAPI Specification 尝试包含大部分的使用场景,在需要时仍然可以通过附加数据来扩展此规范。
此扩展属性被设计为总是以 "x-"
为前缀的模式字段。
字段名模式 | 类型 | 描述 |
^x- | Any | 允许扩展 OpenAPI Schema。此字段名必须以 |
此扩展可能会也可能不会被当前的工具支持,但是可以请求工具开发者支持此扩展(如果工具是内部或开源的)。
Security Filtering
Some objects in the OpenAPI Specification MAY be declared and remain empty, or be completely removed, even though they are inherently the core of the API documentation.
The reasoning is to allow an additional layer of access control over the documentation. While not part of the specification itself, certain libraries MAY choose to allow access to parts of the documentation based on some form of authentication/authorization.
Two examples of this:
The Paths Object MAY be empty. It may be counterintuitive, but this may tell the viewer that they got to the right place, but can't access any documentation. They'd still have access to the Info Object which may contain additional information regarding authentication.
The Path Item Object MAY be empty. In this case, the viewer will be aware that the path exists, but will not be able to see any of its operations or parameters. This is different than hiding the path itself from the Paths Object, so the user will not be aware of its existence. This allows the documentation provider to finely control what the viewer can see.
Appendix A: Revision History
Version | Date | Notes |
3.0.0 | 2017-07-26 | Release of the OpenAPI Specification 3.0.0 |
3.0.0-rc2 | 2017-06-16 | rc2 of the 3.0 specification |
3.0.0-rc1 | 2017-04-27 | rc1 of the 3.0 specification |
3.0.0-rc0 | 2017-02-28 | Implementer's Draft of the 3.0 specification |
2.0 | 2015-12-31 | Donation of Swagger 2.0 to the Open API Initiative |
2.0 | 2014-09-08 | Release of Swagger 2.0 |
1.2 | 2014-03-14 | Initial release of the formal document. |
1.1 | 2012-08-22 | Release of Swagger 1.1 |
1.0 | 2011-08-10 | First release of the Swagger Specification |
Last updated