Copyright © 3001 the Linux Foundation
Text for first chapter
This is the conformance section
Text for first section
Definition of Foo.
Text for second section
Relative link to something else
Text for first subsection
[[RFC3986]]
[[RFC9110]] Section 4
{
"foo": true
}
foo: true
text/plain
no language
unknown language
https://foo.com/bar?baz=qux&fred=waldo#fragment
https://foo.com/bar{?baz*,qux}
--boundary-example
Content-Type: application/openapi+yaml
Content-Location: https://inaccessible-domain.com/api/openapi.yaml
openapi: 3.2.0
info:
title: Example API
version: 1.0
externalDocs:
url: docs.html
--boundary-example
Content-Type: text/html
Content-Location: https://example.com/api/docs.html
<html>
<head>
<title>API Documentation</title>
</head>
<body>
<p>Awesome documentation goes here</p>
</body>
</html>
event: addString
data: This data is formatted
data: across two lines
retry: 5
event: addNumber
data: 1234.5678
unknownField: this is ignored
: This is a comment
event: addJSON
data: {"foo": 42}
{"event": "addString", "data": "This data is formatted\nacross two lines", "retry": 5}
{"event": "addNumber", "data": "1234.5678"}
{"event": "addJSON", "data": "{\"foo\": 42}"}
{"event": "addString", "data": "This data is formatted\nacross two lines", "retry": 5}
{"event": "addNumber", "data": "1234.5678"}
{"event": "addJSON", "data": "{\"foo\": 42}"}
0x1E{
"timestamp": "1985-04-12T23:20:50.52Z",
"level": 1,
"message": "Hi!"
}
0x1E{
"timestamp": "1985-04-12T23:20:51.37Z",
"level": 1,
"message": "Bye!"
}
| Version | Date |
|---|---|
| 30.0.1 | 3001-04-01 |
Awesome documentation goes here
``` ```eventstream event: addString data: This data is formatted data: across two lines retry: 5 event: addNumber data: 1234.5678 unknownField: this is ignored : This is a comment event: addJSON data: {"foo": 42} ``` ```jsonl {"event": "addString", "data": "This data is formatted\nacross two lines", "retry": 5} {"event": "addNumber", "data": "1234.5678"} {"event": "addJSON", "data": "{\"foo\": 42}"} ``` ```ndjson {"event": "addString", "data": "This data is formatted\nacross two lines", "retry": 5} {"event": "addNumber", "data": "1234.5678"} {"event": "addJSON", "data": "{\"foo\": 42}"} ``` ```jsonseq 0x1E{ "timestamp": "1985-04-12T23:20:50.52Z", "level": 1, "message": "Hi!" } 0x1E{ "timestamp": "1985-04-12T23:20:51.37Z", "level": 1, "message": "Bye!" } ``` ## Appendix A: Revision History Version | Date --------|----------- 30.0.1 | 3001-04-01 OpenAPI-Specification-3.2.1/tests/md2html/fixtures/basic-old.html 0000664 0000000 0000000 00000022510 15250560344 0024637 0 ustar 00root root 0000000 0000000Copyright © 3001 the Linux Foundation
Text for first chapter
This is the conformance section
Text for first section
Broken anchor
Text for first subsection
| Version | Date |
|---|---|
| 30.0.1 | 3001-04-01 |
foo|bar. foo|bar. foo|bar. form‑urlencoded |
| [RFC1866](https://datatracker.ietf.org/doc/html/rfc1866#section-8.2.1) | 11/1995 | content-based serialization | [[RFC1738]] | obsoleted by [[HTML401]] [Section 17.13.4.1](https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1), [[URL]] [Section 5](https://url.spec.whatwg.org/#urlencoded-serializing) |
Style-based serialization is used in the [Parameter Object](#parameter-object) when `schema` is present, and in the [Encoding Object](#encoding-object) when at least one of `style`, `explode`, or `allowReserved` is present.
See [Appendix C](#appendix-c-using-rfc6570-based-serialization) for more details of RFC6570's two different approaches to percent-encoding, including an example involving `+`.
Content-based serialization is defined by the [Media Type Object](#media-type-object), and used with the [Parameter Object](#parameter-object) when the `content` field is present, and with the [Encoding Object](#encoding-object) based on the `contentType` field when the fields `style`, `explode`, and `allowReserved` are absent.
Each part is encoded based on the media type (e.g. `text/plain` or `application/json`), and must then be percent-encoded for use in a `form-urlencoded` string.
Note that content-based serialization for `form-data` does not expect or require percent-encoding in the data, only in per-part header values.
#### Interoperability with Historical Specifications
In most cases, generating query strings in strict compliance with [[RFC3986]] is sufficient to pass validation (including JSON Schema's `format: "uri"` and `format: "uri-reference"`), but some `form-urlencoded` implementations still expect the slightly more restrictive [[RFC1738]] rules to be used.
Since all RFC1738-compliant URIs are compliant with RFC3986, applications needing to ensure historical interoperability SHOULD use RFC1738's rules.
#### Interoperability with Web Browser Environments
WHATWG is a [web browser-oriented](https://whatwg.org/faq#what-is-the-whatwg-working-on) standards group that has defined a "URL Living Standard" for parsing and serializing URLs in a browser context, including parsing and serializing `form-urlencoded` data.
WHATWG's percent-encoding rules for query strings are different depending on whether the query string is [being treated as `form-urlencoded`](https://url.spec.whatwg.org/#application-x-www-form-urlencoded-percent-encode-set) (where it requires more percent-encoding than [[RFC1738]]) or [as part of the generic syntax](https://url.spec.whatwg.org/#query-percent-encode-set), where it allows characters that [[RFC3986]] forbids.
Implementations needing maximum compatibility with web browsers SHOULD use WHATWG's `form-urlencoded` percent-encoding rules.
However, they SHOULD NOT rely on WHATWG's less stringent generic query string rules, as the resulting URLs would fail RFC3986 validation, including JSON Schema's `format: uri` and `format: uri-reference`.
### Decoding URIs and `form-urlencoded` Strings
The percent-decoding algorithm does not care which characters were or were not percent-decoded, which means that URIs percent-encoded according to any specification will be decoded correctly.
Similarly, all `form-urlencoded` decoding algorithms simply add `+`-for-space handling to the percent-decoding algorithm, and will work regardless of the encoding specification used.
However, care must be taken to use `form-urlencoded` decoding if `+` represents a space, and to use regular percent-decoding if `+` represents itself as a literal value.
### Percent-Encoding and Illegal or Reserved Delimiters
The `[`, `]`, `|`, and space characters, which are used as delimiters for the `deepObject`, `pipeDelimited`, and `spaceDelimited` styles, respectively, all MUST be percent-encoded to comply with [[RFC3986]].
This requires users to pre-encode the character(s) in some other way in parameter names and values to distinguish them from the delimiter usage when using one of these styles.
The space character is always illegal and encoded in some way by all implementations of all versions of the relevant standards.
While one could use the `form-urlencoded` convention of `+` to distinguish spaces in parameter names and values from `spaceDelimited` delimiters encoded as `%20`, the specifications define the decoding as a single pass, making it impossible to distinguish the different usages in the decoded result.
Some environments use `[`, `]`, and possibly `|` unencoded in query strings without apparent difficulties, and WHATWG's generic query string rules do not require percent-encoding them.
Code that relies on leaving these delimiters unencoded, while using regular percent-encoding for them within names and values, is not guaranteed to be interoperable across all implementations.
For maximum interoperability, it is RECOMMENDED to either define and document an additional escape convention while percent-encoding the delimiters for these styles, or to avoid these styles entirely.
The exact method of additional encoding/escaping is left to the API designer, and is expected to be performed before serialization and encoding described in this specification, and reversed after this specification's encoding and serialization steps are reversed.
This keeps it outside of the processes governed by this specification.
## Appendix F: Resolving Security Requirements in a Referenced Document
This appendix shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. See [Resolving Implicit Connections](#resolving-implicit-connections) for more information.
First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document:
```HTTP
GET /api/description/openapi HTTP/1.1
Host: www.example.com
Accept: application/openapi+json
```
```json
"components": {
"securitySchemes": {
"MySecurity": {
"type": "http",
"scheme": "bearer",
"bearerFormat": "JWT"
}
}
},
"paths": {
"/foo": {
"$ref": "other#/components/pathItems/Foo"
}
}
```
```HTTP
GET /api/description/openapi HTTP/1.1
Host: www.example.com
Accept: application/openapi+yaml
```
```yaml
components:
securitySchemes:
MySecurity:
type: http
scheme: bearer
bearerFormat: JWT
paths:
/foo:
$ref: 'other#/components/pathItems/Foo'
```
This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available:
```HTTP
GET /api/description/other HTTP/1.1
Host: www.example.com
Accept: application/openapi+json
```
```json
"components": {
"securitySchemes": {
"MySecurity": {
"type": "http",
"scheme": "basic"
}
},
"pathItems": {
"Foo": {
"get": {
"security": [
"MySecurity": []
]
}
}
}
}
```
```HTTP
GET /api/description/other HTTP/1.1
Host: www.example.com
Accept: application/openapi+yaml
```
```yaml
components:
securitySchemes:
MySecurity:
type: http
scheme: basic
pathItems:
Foo:
get:
security:
- MySecurity: []
```
In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior). However, documented in that section, it is RECOMMENDED that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported.
OpenAPI-Specification-3.2.1/versions/3.1.0-editors.md 0000664 0000000 0000000 00000000741 15250560344 0022034 0 ustar 00root root 0000000 0000000 ## Active
* Darrel Miller [@darrelmiller](https://github.com/darrelmiller)
* Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc)
* Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh)
* Mike Ralphson [@MikeRalphson](https://github.com/MikeRalphson)
* Ron Ratovsky [@webron](https://github.com/webron)
* Uri Sarid [@usarid](https://github.com/usarid)
## Emeritus
* Jason Harmon [@jharmn](https://github.com/jharmn)
* Tony Tam [@fehguy](https://github.com/fehguy)
OpenAPI-Specification-3.2.1/versions/3.1.0.md 0000664 0000000 0000000 00000376360 15250560344 0020402 0 ustar 00root root 0000000 0000000 # OpenAPI Specification
#### Version 3.1.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](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
## Introduction
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
## Table of Contents
- [Definitions](#definitions)
- [OpenAPI Document](#openapi-document)
- [Path Templating](#path-templating)
- [Media Types](#media-types)
- [HTTP Status Codes](#http-status-codes)
- [Specification](#specification)
- [Versions](#versions)
- [Format](#format)
- [Document Structure](#document-structure)
- [Data Types](#data-types)
- [Rich Text Formatting](#rich-text-formatting)
- [Relative References In URIs](#relative-references-in-uris)
- [Relative References In URLs](#relative-references-in-urls)
- [Schema](#schema)
- [OpenAPI Object](#openapi-object)
- [Info Object](#info-object)
- [Contact Object](#contact-object)
- [License Object](#license-object)
- [Server Object](#server-object)
- [Server Variable Object](#server-variable-object)
- [Components Object](#components-object)
- [Paths Object](#paths-object)
- [Path Item Object](#path-item-object)
- [Operation Object](#operation-object)
- [External Documentation Object](#external-documentation-object)
- [Parameter Object](#parameter-object)
- [Request Body Object](#request-body-object)
- [Media Type Object](#media-type-object)
- [Encoding Object](#encoding-object)
- [Responses Object](#responses-object)
- [Response Object](#response-object)
- [Callback Object](#callback-object)
- [Example Object](#example-object)
- [Link Object](#link-object)
- [Header Object](#header-object)
- [Tag Object](#tag-object)
- [Reference Object](#reference-object)
- [Schema Object](#schema-object)
- [Discriminator Object](#discriminator-object)
- [XML Object](#xml-object)
- [Security Scheme Object](#security-scheme-object)
- [OAuth Flows Object](#oauth-flows-object)
- [OAuth Flow Object](#oauth-flow-object)
- [Security Requirement Object](#security-requirement-object)
- [Specification Extensions](#specification-extensions)
- [Security Filtering](#security-filtering)
- [Appendix A: Revision History](#appendix-a-revision-history)
## Definitions
##### OpenAPI Document
A self-contained or composite resource which defines or describes an API or elements of an API. The OpenAPI document MUST contain at least one [paths](#paths-object) field, a [components](#oasComponents) field or a [webhooks](#oasWebhooks) field. An OpenAPI document uses and conforms to the OpenAPI Specification.
##### Path Templating
Path templating refers to the usage of template expressions, delimited by curly braces ({}), to mark a section of a URL path as replaceable using path parameters.
Each template expression in the path MUST correspond to a path parameter that is included in the [Path Item](#path-item-object) itself and/or in each of the Path Item's [Operations](#operation-object). An exception is if the path item is empty, for example due to ACL constraints, matching path parameters are not required.
The value for these path parameters MUST NOT contain any unescaped "generic syntax" characters described by [RFC3986](https://tools.ietf.org/html/rfc3986#section-3): forward slashes (`/`), question marks (`?`), or hashes (`#`).
##### Media Types
Media type definitions are spread across several resources.
The media type definitions SHOULD be in compliance with [RFC6838](https://tools.ietf.org/html/rfc6838).
Some examples of possible media type definitions:
```
text/plain; charset=utf-8
application/json
application/vnd.github+json
application/vnd.github.v3+json
application/vnd.github.v3.raw+json
application/vnd.github.v3.text+json
application/vnd.github.v3.html+json
application/vnd.github.v3.full+json
application/vnd.github.v3.diff
application/vnd.github.v3.patch
```
##### HTTP Status Codes
The HTTP Status Codes are used to indicate the status of the executed operation.
The available status codes are defined by [RFC7231](https://tools.ietf.org/html/rfc7231#section-6) and registered status codes are listed in the [IANA Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml).
## Specification
### Versions
The OpenAPI Specification is versioned using a `major`.`minor`.`patch` versioning scheme. The `major`.`minor` portion of the version string (for example `3.1`) SHALL designate the OAS feature set. *`.patch`* versions address errors in, or provide clarifications to, this document, not the feature set. Tooling which supports OAS 3.1 SHOULD be compatible with all OAS 3.1.\* versions. The patch version SHOULD NOT be considered by tooling, making no distinction between `3.1.0` and `3.1.1` for example.
Occasionally, non-backwards compatible changes may be made in `minor` versions of the OAS where impact is believed to be low relative to the benefit provided.
An OpenAPI document compatible with OAS 3.\*.\* contains a required [`openapi`](#oasVersion) field which designates the version of the OAS that it uses.
### Format
An OpenAPI document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or YAML format.
For example, if a field has an array value, the JSON array representation will be used:
```json
{
"field": [ 1, 2, 3 ]
}
```
All field names in the specification are **case sensitive**.
This includes all fields that are used as keys in a map, except where explicitly noted that keys are **case insensitive**.
The schema exposes two types of fields: Fixed fields, which have a declared name, and Patterned fields, which declare a regex pattern for the field name.
Patterned fields MUST have unique names within the containing object.
In order to preserve the ability to round-trip between YAML and JSON formats, YAML version [1.2](https://yaml.org/spec/1.2/spec.html) is RECOMMENDED along with some additional constraints:
- Tags MUST be limited to those allowed by the [JSON Schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231).
- Keys used in YAML maps MUST be limited to a scalar string, as defined by the [YAML Failsafe schema ruleset](https://yaml.org/spec/1.2/spec.html#id2802346).
**Note:** While APIs may be defined by OpenAPI documents in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.
### Document Structure
An OpenAPI document MAY be made up of a single document or be divided into multiple, connected parts at the discretion of the author. In the latter case, [`Reference Objects`](#reference-object) and [`Schema Object`](#schema-object) `$ref` keywords are used.
It is RECOMMENDED that the root OpenAPI document be named: `openapi.json` or `openapi.yaml`.
### Data Types
Data types in the OAS are based on the types supported by the [JSON Schema Specification Draft 2020-12](https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-4.2.1).
Note that `integer` as a type is also supported and is defined as a JSON number without a fraction or exponent part.
Models are defined using the [Schema Object](#schema-object), which is a superset of JSON Schema Specification Draft 2020-12.
As defined by the [JSON Schema Validation vocabulary](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier property: `format`.
OAS defines additional formats to provide fine detail for primitive data types.
The formats defined by the OAS are:
[`type`](#data-types) | [`format`](#dataTypeFormat) | Comments
------ | -------- | --------
`integer` | `int32` | signed 32 bits
`integer` | `int64` | signed 64 bits (a.k.a long)
`number` | `float` | |
`number` | `double` | |
`string` | `password` | A hint to UIs to obscure input.
### Rich Text Formatting
Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting.
Where OpenAPI tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [CommonMark 0.27](https://spec.commonmark.org/0.27/). Tooling MAY choose to ignore some CommonMark features to address security concerns.
### Relative References in URIs
Unless specified otherwise, all properties that are URIs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Relative references, including those in [`Reference Objects`](#reference-object), [`PathItem Object`](#path-item-object) `$ref` fields, [`Link Object`](#link-object) `operationRef` fields and [`Example Object`](#example-object) `externalValue` fields, are resolved using the referring document as the Base URI according to [RFC3986](https://tools.ietf.org/html/rfc3986#section-5.2).
If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document. If the representation of the referenced document is JSON or YAML, then the fragment identifier SHOULD be interpreted as a JSON-Pointer as per [RFC6901](https://tools.ietf.org/html/rfc6901).
Relative references in [`Schema Objects`](#schema-object), including any that appear as `$id` values, use the nearest parent `$id` as a Base URI, as described by [JSON Schema Specification Draft 2020-12](https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2). If no parent schema contains an `$id`, then the Base URI MUST be determined according to [RFC3986](https://tools.ietf.org/html/rfc3986#section-5.1).
### Relative References in URLs
Unless specified otherwise, all properties that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Unless specified otherwise, relative references are resolved using the URLs defined in the [`Server Object`](#server-object) as a Base URL. Note that these themselves MAY be relative to the referring document.
### Schema
In the following description, if a field is not explicitly **REQUIRED** or described with a MUST or SHALL, it can be considered OPTIONAL.
#### OpenAPI Object
This is the root object of the [OpenAPI document](#openapi-document).
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI document. This is *not* related to the API [`info.version`](#infoVersion) string.
info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required.
jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI.
servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` property is not provided, or is an empty array, the default value would be a [Server Object](#server-object) with a [url](#serverUrl) value of `/`.
paths | [Paths Object](#paths-object) | The available paths and operations for the API.
webhooks | Map[`string`, [Path Item Object](#path-item-object) \| [Reference Object](#reference-object)] ] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](../examples/v3.1/webhook-example.yaml) is available.
components | [Components Object](#components-object) | An element to hold various schemas for the document.
security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. Individual operations can override this definition. To make security optional, an empty security requirement (`{}`) can be included in the array.
tags | [[Tag Object](#tag-object)] | A list of tags used by the document with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique.
externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation.
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Info Object
The object provides metadata about the API.
The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
title | `string` | **REQUIRED**. The title of the API.
summary | `string` | A short summary of the API.
description | `string` | A description of the API. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
termsOfService | `string` | A URL to the Terms of Service for the API. This MUST be in the form of a URL.
contact | [Contact Object](#contact-object) | The contact information for the exposed API.
license | [License Object](#license-object) | The license information for the exposed API.
version | `string` | **REQUIRED**. The version of the OpenAPI document (which is distinct from the [OpenAPI Specification version](#oasVersion) or the API implementation version).
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Info Object Example
```json
{
"title": "Sample Pet Store App",
"summary": "A pet store manager.",
"description": "This is a sample server for a pet store.",
"termsOfService": "https://example.com/terms/",
"contact": {
"name": "API Support",
"url": "https://www.example.com/support",
"email": "support@example.com"
},
"license": {
"name": "Apache 2.0",
"url": "https://www.apache.org/licenses/LICENSE-2.0.html"
},
"version": "1.0.1"
}
```
```yaml
title: Sample Pet Store App
summary: A pet store manager.
description: This is a sample server for a pet store.
termsOfService: https://example.com/terms/
contact:
name: API Support
url: https://www.example.com/support
email: support@example.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.1
```
#### Contact Object
Contact information for the exposed API.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
name | `string` | The identifying name of the contact person/organization.
url | `string` | The URL pointing to the contact information. This MUST be in the form of a URL.
email | `string` | The email address of the contact person/organization. This MUST be in the form of an email address.
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Contact Object Example
```json
{
"name": "API Support",
"url": "https://www.example.com/support",
"email": "support@example.com"
}
```
```yaml
name: API Support
url: https://www.example.com/support
email: support@example.com
```
#### License Object
License information for the exposed API.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
name | `string` | **REQUIRED**. The license name used for the API.
identifier | `string` | An [SPDX](https://spdx.org/licenses/) license expression for the API. The `identifier` field is mutually exclusive of the `url` field.
url | `string` | A URL to the license used for the API. This MUST be in the form of a URL. The `url` field is mutually exclusive of the `identifier` field.
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### License Object Example
```json
{
"name": "Apache 2.0",
"identifier": "Apache-2.0"
}
```
```yaml
name: Apache 2.0
identifier: Apache-2.0
```
#### Server Object
An object representing a Server.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the OpenAPI document is being served. Variable substitutions will be made when a variable is named in `{`brackets`}`.
description | `string` | An optional string describing the host designated by the URL. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is used for substitution in the server's URL template.
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Server Object Example
A single server would be described as:
```json
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
}
```
```yaml
url: https://development.gigantic-server.com/v1
description: Development server
```
The following shows how multiple servers can be described, for example, at the OpenAPI Object's [`servers`](#oasServers):
```json
{
"servers": [
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
},
{
"url": "https://staging.gigantic-server.com/v1",
"description": "Staging server"
},
{
"url": "https://api.gigantic-server.com/v1",
"description": "Production server"
}
]
}
```
```yaml
servers:
- url: https://development.gigantic-server.com/v1
description: Development server
- url: https://staging.gigantic-server.com/v1
description: Staging server
- url: https://api.gigantic-server.com/v1
description: Production server
```
The following shows how variables can be used for a server configuration:
```json
{
"servers": [
{
"url": "https://{username}.gigantic-server.com:{port}/{basePath}",
"description": "The production API server",
"variables": {
"username": {
"default": "demo",
"description": "this value is assigned by the service provider, in this example `gigantic-server.com`"
},
"port": {
"enum": [
"8443",
"443"
],
"default": "8443"
},
"basePath": {
"default": "v2"
}
}
}
]
}
```
```yaml
servers:
- url: https://{username}.gigantic-server.com:{port}/{basePath}
description: The production API server
variables:
username:
# note! no enum here means it is an open value
default: demo
description: this value is assigned by the service provider, in this example `gigantic-server.com`
port:
enum:
- '8443'
- '443'
default: '8443'
basePath:
# open meaning there is the opportunity to use special base paths as assigned by the provider, default is `v2`
default: v2
```
#### Server Variable Object
An object representing a Server Variable for server URL template substitution.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array MUST NOT be empty.
default | `string` | **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. Note this behavior is different than the [Schema Object's](#schema-object) treatment of default values, because in those cases parameter values are optional. If the [`enum`](#serverVariableEnum) is defined, the value MUST exist in the enum's values.
description | `string` | An optional description for the server variable. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Components Object
Holds a set of reusable objects for different aspects of the OAS.
All objects defined within the components object will have no effect on the API unless they are explicitly referenced from properties outside the components object.
##### Fixed Fields
Field Name | Type | Description
---|:---|---
schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object).
responses | Map[`string`, [Response Object](#response-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Response Objects](#response-object).
parameters | Map[`string`, [Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Parameter Objects](#parameter-object).
examples | Map[`string`, [Example Object](#example-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Example Objects](#example-object).
requestBodies | Map[`string`, [Request Body Object](#request-body-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Request Body Objects](#request-body-object).
headers | Map[`string`, [Header Object](#header-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Header Objects](#header-object).
securitySchemes| Map[`string`, [Security Scheme Object](#security-scheme-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Security Scheme Objects](#security-scheme-object).
links | Map[`string`, [Link Object](#link-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Link Objects](#link-object).
callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Callback Objects](#callback-object).
pathItems | Map[`string`, [Path Item Object](#path-item-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Path Item Object](#path-item-object).
This object MAY be extended with [Specification Extensions](#specification-extensions).
All the fixed fields declared above are objects that MUST use keys that match the regular expression: `^[a-zA-Z0-9\.\-_]+$`.
Field Name Examples:
```
User
User_1
User_Name
user-name
my.org.User
```
##### Components Object Example
```json
"components": {
"schemas": {
"GeneralError": {
"type": "object",
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
}
}
},
"Category": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
}
}
},
"Tag": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
}
}
}
},
"parameters": {
"skipParam": {
"name": "skip",
"in": "query",
"description": "number of items to skip",
"required": true,
"schema": {
"type": "integer",
"format": "int32"
}
},
"limitParam": {
"name": "limit",
"in": "query",
"description": "max records to return",
"required": true,
"schema" : {
"type": "integer",
"format": "int32"
}
}
},
"responses": {
"NotFound": {
"description": "Entity not found."
},
"IllegalInput": {
"description": "Illegal input for operation."
},
"GeneralError": {
"description": "General Error",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/GeneralError"
}
}
}
}
},
"securitySchemes": {
"api_key": {
"type": "apiKey",
"name": "api_key",
"in": "header"
},
"petstore_auth": {
"type": "oauth2",
"flows": {
"implicit": {
"authorizationUrl": "https://example.org/api/oauth/dialog",
"scopes": {
"write:pets": "modify pets in your account",
"read:pets": "read your pets"
}
}
}
}
}
}
```
```yaml
components:
schemas:
GeneralError:
type: object
properties:
code:
type: integer
format: int32
message:
type: string
Category:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
Tag:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
parameters:
skipParam:
name: skip
in: query
description: number of items to skip
required: true
schema:
type: integer
format: int32
limitParam:
name: limit
in: query
description: max records to return
required: true
schema:
type: integer
format: int32
responses:
NotFound:
description: Entity not found.
IllegalInput:
description: Illegal input for operation.
GeneralError:
description: General Error
content:
application/json:
schema:
$ref: '#/components/schemas/GeneralError'
securitySchemes:
api_key:
type: apiKey
name: api_key
in: header
petstore_auth:
type: oauth2
flows:
implicit:
authorizationUrl: https://example.org/api/oauth/dialog
scopes:
write:pets: modify pets in your account
read:pets: read your pets
```
#### Paths Object
Holds the relative paths to the individual endpoints and their operations.
The path is appended to the URL from the [`Server Object`](#server-object) in order to construct the full URL. The Paths MAY be empty, due to [Access Control List (ACL) constraints](#security-filtering).
##### Patterned Fields
Field Pattern | Type | Description
---|:---:|---
/{path} | [Path Item Object](#path-item-object) | A relative path to an individual endpoint. The field name MUST begin with a forward slash (`/`). The path is **appended** (no relative URL resolution) to the expanded URL from the [`Server Object`](#server-object)'s `url` field in order to construct the full URL. [Path templating](#path-templating) is allowed. When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it's up to the tooling to decide which one to use.
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Path Templating Matching
Assuming the following paths, the concrete definition, `/pets/mine`, will be matched first if used:
```
/pets/{petId}
/pets/mine
```
The following paths are considered identical and invalid:
```
/pets/{petId}
/pets/{name}
```
The following may lead to ambiguous resolution:
```
/{entity}/me
/books/{id}
```
##### Paths Object Example
```json
{
"/pets": {
"get": {
"description": "Returns all pets from the system that the user has access to",
"responses": {
"200": {
"description": "A list of pets.",
"content": {
"application/json": {
"schema": {
"type": "array",
"items": {
"$ref": "#/components/schemas/pet"
}
}
}
}
}
}
}
}
}
```
```yaml
/pets:
get:
description: Returns all pets from the system that the user has access to
responses:
'200':
description: A list of pets.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/pet'
```
#### Path Item Object
Describes the operations available on a single path.
A Path Item MAY be empty, due to [ACL constraints](#security-filtering).
The path itself is still exposed to the documentation viewer but they will not know which operations and parameters are available.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
$ref | `string` | Allows for a referenced definition of this path item. The referenced structure MUST be in the form of a [Path Item Object](#path-item-object). In case a Path Item Object field appears both in the defined object and the referenced object, the behavior is undefined. See the rules for resolving [Relative References](#relative-references-in-uris).
summary| `string` | An optional, string summary, intended to apply to all operations in this path.
description | `string` | An optional, string description, intended to apply to all operations in this path. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
get | [Operation Object](#operation-object) | A definition of a GET operation on this path.
put | [Operation Object](#operation-object) | A definition of a PUT operation on this path.
post | [Operation Object](#operation-object) | A definition of a POST operation on this path.
delete | [Operation Object](#operation-object) | A definition of a DELETE operation on this path.
options | [Operation Object](#operation-object) | A definition of a OPTIONS operation on this path.
head | [Operation Object](#operation-object) | A definition of a HEAD operation on this path.
patch | [Operation Object](#operation-object) | A definition of a PATCH operation on this path.
trace | [Operation Object](#operation-object) | A definition of a TRACE operation on this path.
servers | [[Server Object](#server-object)] | An alternative `server` array to service all operations in this path.
parameters | [[Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | A list of parameters that are applicable for all the operations described under this path. These parameters can be overridden at the operation level, but cannot be removed there. The list MUST NOT include duplicated parameters. A unique parameter is defined by a combination of a [name](#parameterName) and [location](#parameterIn). The list can use the [Reference Object](#reference-object) to link to parameters that are defined at the [OpenAPI Object's components/parameters](#componentsParameters).
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Path Item Object Example
```json
{
"get": {
"description": "Returns pets based on ID",
"summary": "Find pets by ID",
"operationId": "getPetsById",
"responses": {
"200": {
"description": "pet response",
"content": {
"*/*": {
"schema": {
"type": "array",
"items": {
"$ref": "#/components/schemas/Pet"
}
}
}
}
},
"default": {
"description": "error payload",
"content": {
"text/html": {
"schema": {
"$ref": "#/components/schemas/ErrorModel"
}
}
}
}
}
},
"parameters": [
{
"name": "id",
"in": "path",
"description": "ID of pet to use",
"required": true,
"schema": {
"type": "array",
"items": {
"type": "string"
}
},
"style": "simple"
}
]
}
```
```yaml
get:
description: Returns pets based on ID
summary: Find pets by ID
operationId: getPetsById
responses:
'200':
description: pet response
content:
'*/*' :
schema:
type: array
items:
$ref: '#/components/schemas/Pet'
default:
description: error payload
content:
'text/html':
schema:
$ref: '#/components/schemas/ErrorModel'
parameters:
- name: id
in: path
description: ID of pet to use
required: true
schema:
type: array
items:
type: string
style: simple
```
#### Operation Object
Describes a single API operation on a path.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
tags | [`string`] | A list of tags for API documentation control. Tags can be used for logical grouping of operations by resources or any other qualifier.
summary | `string` | A short summary of what the operation does.
description | `string` | A verbose explanation of the operation behavior. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation for this operation.
operationId | `string` | Unique string used to identify the operation. The id MUST be unique among all operations described in the API. The operationId value is **case-sensitive**. Tools and libraries MAY use the operationId to uniquely identify an operation, therefore, it is RECOMMENDED to follow common programming naming conventions.
parameters | [[Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | A list of parameters that are applicable for this operation. If a parameter is already defined at the [Path Item](#pathItemParameters), the new definition will override it but can never remove it. The list MUST NOT include duplicated parameters. A unique parameter is defined by a combination of a [name](#parameterName) and [location](#parameterIn). The list can use the [Reference Object](#reference-object) to link to parameters that are defined at the [OpenAPI Object's components/parameters](#componentsParameters).
requestBody | [Request Body Object](#request-body-object) \| [Reference Object](#reference-object) | The request body applicable for this operation. The `requestBody` is fully supported in HTTP methods where the HTTP 1.1 specification [RFC7231](https://tools.ietf.org/html/rfc7231#section-4.3.1) has explicitly defined semantics for request bodies. In other cases where the HTTP spec is vague (such as [GET](https://tools.ietf.org/html/rfc7231#section-4.3.1), [HEAD](https://tools.ietf.org/html/rfc7231#section-4.3.2) and [DELETE](https://tools.ietf.org/html/rfc7231#section-4.3.5)), `requestBody` is permitted but does not have well-defined semantics and SHOULD be avoided if possible.
responses | [Responses Object](#responses-object) | The list of possible responses as they are returned from executing this operation.
callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | A map of possible out-of band callbacks related to the parent operation. The key is a unique identifier for the Callback Object. Each value in the map is a [Callback Object](#callback-object) that describes a request that may be initiated by the API provider and the expected responses.
deprecated | `boolean` | Declares this operation to be deprecated. Consumers SHOULD refrain from usage of the declared operation. Default value is `false`.
security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used for this operation. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. To make security optional, an empty security requirement (`{}`) can be included in the array. This definition overrides any declared top-level [`security`](#oasSecurity). To remove a top-level security declaration, an empty array can be used.
servers | [[Server Object](#server-object)] | An alternative `server` array to service this operation. If an alternative `server` object is specified at the Path Item Object or Root level, it will be overridden by this value.
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Operation Object Example
```json
{
"tags": [
"pet"
],
"summary": "Updates a pet in the store with form data",
"operationId": "updatePetWithForm",
"parameters": [
{
"name": "petId",
"in": "path",
"description": "ID of pet that needs to be updated",
"required": true,
"schema": {
"type": "string"
}
}
],
"requestBody": {
"content": {
"application/x-www-form-urlencoded": {
"schema": {
"type": "object",
"properties": {
"name": {
"description": "Updated name of the pet",
"type": "string"
},
"status": {
"description": "Updated status of the pet",
"type": "string"
}
},
"required": ["status"]
}
}
}
},
"responses": {
"200": {
"description": "Pet updated.",
"content": {
"application/json": {},
"application/xml": {}
}
},
"405": {
"description": "Method Not Allowed",
"content": {
"application/json": {},
"application/xml": {}
}
}
},
"security": [
{
"petstore_auth": [
"write:pets",
"read:pets"
]
}
]
}
```
```yaml
tags:
- pet
summary: Updates a pet in the store with form data
operationId: updatePetWithForm
parameters:
- name: petId
in: path
description: ID of pet that needs to be updated
required: true
schema:
type: string
requestBody:
content:
'application/x-www-form-urlencoded':
schema:
type: object
properties:
name:
description: Updated name of the pet
type: string
status:
description: Updated status of the pet
type: string
required:
- status
responses:
'200':
description: Pet updated.
content:
'application/json': {}
'application/xml': {}
'405':
description: Method Not Allowed
content:
'application/json': {}
'application/xml': {}
security:
- petstore_auth:
- write:pets
- read:pets
```
#### External Documentation Object
Allows referencing an external resource for extended documentation.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
description | `string` | A description of the target documentation. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
url | `string` | **REQUIRED**. The URL for the target documentation. This MUST be in the form of a URL.
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### External Documentation Object Example
```json
{
"description": "Find more info here",
"url": "https://example.com"
}
```
```yaml
description: Find more info here
url: https://example.com
```
#### Parameter Object
Describes a single operation parameter.
A unique parameter is defined by a combination of a [name](#parameterName) and [location](#parameterIn).
##### Parameter Locations
There are four possible parameter locations specified by the `in` field:
* path - Used together with [Path Templating](#path-templating), where the parameter value is actually part of the operation's URL. This does not include the host or base path of the API. For example, in `/items/{itemId}`, the path parameter is `itemId`.
* query - Parameters that are appended to the URL. For example, in `/items?id=###`, the query parameter is `id`.
* header - Custom headers that are expected as part of the request. Note that [RFC7230](https://tools.ietf.org/html/rfc7230#page-22) states header names are case insensitive.
* cookie - Used to pass a specific cookie value to the API.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
name | `string` | **REQUIRED**. The name of the parameter. Parameter names are *case sensitive*. type: stringformat: binary | contentMediaType: image/png | if redundant, can be omitted, often resulting in an empty [Schema Object](#schema-object) |
| type: stringformat: byte | type: stringcontentMediaType: image/pngcontentEncoding: base64 | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe |
### Rich Text Formatting
Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting.
Where OpenAPI tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [CommonMark 0.27](https://spec.commonmark.org/0.27/). Tooling MAY choose to ignore some CommonMark or extension features to address security concerns.
While the framing of CommonMark 0.27 as a minimum requirement means that tooling MAY choose to implement extensions on top of it, note that any such extensions are by definition implementation-defined and will not be interoperable.
OpenAPI Description authors SHOULD consider how text using such extensions will be rendered by tools that offer only the minimum support.
### Relative References in API Description URIs
URIs used as references within an OpenAPI Description, or to external documentation or other supplementary information such as a license, are resolved as _identifiers_, and described by this specification as **_URIs_**.
As noted under [Parsing Documents](#parsing-documents), this specification inherits JSON Schema Specification Draft 2020-12's requirements for [loading documents](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-9) and associating them with their expected URIs, which might not match their current location.
This feature is used both for working in development or test environments without having to change the URIs, and for working within restrictive network configurations or security policies.
Note that some URI fields are named `url` for historical reasons, but the descriptive text for those fields uses the correct "URI" terminology.
Unless specified otherwise, all fields that are URIs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Relative references in [Schema Objects](#schema-object), including any that appear as `$id` values, use the nearest parent `$id` as a Base URI, as described by [JSON Schema Specification Draft 2020-12](https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2).
Relative URI references in other Objects, and in Schema Objects where no parent schema contains an `$id`, MUST be resolved using the referring document's base URI, which is determined in accordance with [[RFC3986]] [Section 5.1.2 – 5.1.4](https://tools.ietf.org/html/rfc3986#section-5.1.2).
In practice, this is usually the retrieval URI of the document, which MAY be determined based on either its current actual location or a user-supplied expected location.
If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document. If the representation of the referenced document is JSON or YAML, then the fragment identifier SHOULD be interpreted as a JSON-Pointer as per [RFC6901](https://tools.ietf.org/html/rfc6901).
Relative references in CommonMark hyperlinks are resolved in their rendered context, which might differ from the context of the API description.
### Relative References in API URLs
API endpoints are by definition accessed as locations, and are described by this specification as **_URLs_**.
Unless specified otherwise, all fields that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Unless specified otherwise, relative references are resolved using the URLs defined in the [Server Object](#server-object) as a Base URL. Note that these themselves MAY be relative to the referring document.
### Schema
This section describes the structure of the OpenAPI Description format.
This text is the only normative description of the format.
A JSON Schema is hosted on [spec.openapis.org](https://spec.openapis.org) for informational purposes.
If the JSON Schema differs from this section, then this section MUST be considered authoritative.
In the following description, if a field is not explicitly **REQUIRED** or described with a MUST or SHALL, it can be considered OPTIONAL.
#### OpenAPI Object
This is the root object of the [OpenAPI Description](#openapi-description).
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI Document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI Document. This is _not_ related to the API [`info.version`](#info-version) string. |
| info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required. |
| jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI. |
| servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` field is not provided, or is an empty array, the default value would be a [Server Object](#server-object) with a [url](#server-url) value of `/`. |
| paths | [Paths Object](#paths-object) | The available paths and operations for the API. |
| webhooks | Map[`string`, [Path Item Object](#path-item-object)] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](https://learn.openapis.org/examples/v3.1/webhook-example.html) is available. |
| components | [Components Object](#components-object) | An element to hold various Objects for the OpenAPI Description. |
| security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. The list can be incomplete, up to being empty or absent. To make security explicitly optional, an empty security requirement (`{}`) can be included in the array. |
| tags | [[Tag Object](#tag-object)] | A list of tags used by the OpenAPI Description with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique. |
| externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Info Object
The object provides metadata about the API.
The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| title | `string` | **REQUIRED**. The title of the API. |
| summary | `string` | A short summary of the API. |
| description | `string` | A description of the API. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
| termsOfService | `string` | A URI for the Terms of Service for the API. This MUST be in the form of a URI. |
| contact | [Contact Object](#contact-object) | The contact information for the exposed API. |
| license | [License Object](#license-object) | The license information for the exposed API. |
| version | `string` | **REQUIRED**. The version of the OpenAPI Document (which is distinct from the [OpenAPI Specification version](#oas-version) or the version of the API being described or the version of the OpenAPI Description). |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Info Object Example
```json
{
"title": "Example Pet Store App",
"summary": "A pet store manager.",
"description": "This is an example server for a pet store.",
"termsOfService": "https://example.com/terms/",
"contact": {
"name": "API Support",
"url": "https://www.example.com/support",
"email": "support@example.com"
},
"license": {
"name": "Apache 2.0",
"url": "https://www.apache.org/licenses/LICENSE-2.0.html"
},
"version": "1.0.1"
}
```
```yaml
title: Example Pet Store App
summary: A pet store manager.
description: This is an example server for a pet store.
termsOfService: https://example.com/terms/
contact:
name: API Support
url: https://www.example.com/support
email: support@example.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.1
```
#### Contact Object
Contact information for the exposed API.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| name | `string` | The identifying name of the contact person/organization. |
| url | `string` | The URI for the contact information. This MUST be in the form of a URI. |
| email | `string` | The email address of the contact person/organization. This MUST be in the form of an email address. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Contact Object Example
```json
{
"name": "API Support",
"url": "https://www.example.com/support",
"email": "support@example.com"
}
```
```yaml
name: API Support
url: https://www.example.com/support
email: support@example.com
```
#### License Object
License information for the exposed API.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| name | `string` | **REQUIRED**. The license name used for the API. |
| identifier | `string` | An [SPDX](https://spdx.org/licenses/) license expression for the API. The `identifier` field is mutually exclusive of the `url` field. |
| url | `string` | A URI for the license used for the API. This MUST be in the form of a URI. The `url` field is mutually exclusive of the `identifier` field. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### License Object Example
```json
{
"name": "Apache 2.0",
"identifier": "Apache-2.0"
}
```
```yaml
name: Apache 2.0
identifier: Apache-2.0
```
#### Server Object
An object representing a Server.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the document containing the Server Object is being served. Variable substitutions will be made when a variable is named in `{`braces`}`. |
| description | `string` | An optional string describing the host designated by the URL. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
| variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is used for substitution in the server's URL template. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Server Object Example
A single server would be described as:
```json
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
}
```
```yaml
url: https://development.gigantic-server.com/v1
description: Development server
```
The following shows how multiple servers can be described, for example, at the OpenAPI Object's [`servers`](#oas-servers):
```json
{
"servers": [
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
},
{
"url": "https://staging.gigantic-server.com/v1",
"description": "Staging server"
},
{
"url": "https://api.gigantic-server.com/v1",
"description": "Production server"
}
]
}
```
```yaml
servers:
- url: https://development.gigantic-server.com/v1
description: Development server
- url: https://staging.gigantic-server.com/v1
description: Staging server
- url: https://api.gigantic-server.com/v1
description: Production server
```
The following shows how variables can be used for a server configuration:
```json
{
"servers": [
{
"url": "https://{username}.gigantic-server.com:{port}/{basePath}",
"description": "The production API server",
"variables": {
"username": {
"default": "demo",
"description": "A user-specific subdomain. Use `demo` for a free sandbox environment."
},
"port": {
"enum": ["8443", "443"],
"default": "8443"
},
"basePath": {
"default": "v2"
}
}
}
]
}
```
```yaml
servers:
- url: https://{username}.gigantic-server.com:{port}/{basePath}
description: The production API server
variables:
username:
# note! no enum here means it is an open value
default: demo
description: A user-specific subdomain. Use `demo` for a free sandbox environment.
port:
enum:
- '8443'
- '443'
default: '8443'
basePath:
# open meaning there is the opportunity to use special base paths as assigned by the provider, default is `v2`
default: v2
```
#### Server Variable Object
An object representing a Server Variable for server URL template substitution.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array MUST NOT be empty. |
| default | `string` | **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. If the [`enum`](#server-variable-enum) is defined, the value MUST exist in the enum's values. Note that this behavior is different from the [Schema Object](#schema-object)'s `default` keyword, which documents the receiver's behavior rather than inserting the value into the data. |
| description | `string` | An optional description for the server variable. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Components Object
Holds a set of reusable objects for different aspects of the OAS.
All objects defined within the Components Object will have no effect on the API unless they are explicitly referenced from outside the Components Object.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :---- | ---- |
| schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object). |
| responses | Map[`string`, [Response Object](#response-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Response Objects](#response-object). |
| parameters | Map[`string`, [Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Parameter Objects](#parameter-object). |
| examples | Map[`string`, [Example Object](#example-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Example Objects](#example-object). |
| requestBodies | Map[`string`, [Request Body Object](#request-body-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Request Body Objects](#request-body-object). |
| headers | Map[`string`, [Header Object](#header-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Header Objects](#header-object). |
| securitySchemes | Map[`string`, [Security Scheme Object](#security-scheme-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Security Scheme Objects](#security-scheme-object). |
| links | Map[`string`, [Link Object](#link-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Link Objects](#link-object). |
| callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Callback Objects](#callback-object). |
| pathItems | Map[`string`, [Path Item Object](#path-item-object)] | An object to hold reusable [Path Item Objects](#path-item-object). |
This object MAY be extended with [Specification Extensions](#specification-extensions).
All the fixed fields declared above are objects that MUST use keys that match the regular expression: `^[a-zA-Z0-9\.\-_]+$`.
Field Name Examples:
```text
User
User_1
User_Name
user-name
my.org.User
```
##### Components Object Example
```json
"components": {
"schemas": {
"GeneralError": {
"type": "object",
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
}
}
},
"Category": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
}
}
},
"Tag": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
}
}
}
},
"parameters": {
"skipParam": {
"name": "skip",
"in": "query",
"description": "number of items to skip",
"required": true,
"schema": {
"type": "integer",
"format": "int32"
}
},
"limitParam": {
"name": "limit",
"in": "query",
"description": "max records to return",
"required": true,
"schema" : {
"type": "integer",
"format": "int32"
}
}
},
"responses": {
"NotFound": {
"description": "Entity not found."
},
"IllegalInput": {
"description": "Illegal input for operation."
},
"GeneralError": {
"description": "General Error",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/GeneralError"
}
}
}
}
},
"securitySchemes": {
"api_key": {
"type": "apiKey",
"name": "api-key",
"in": "header"
},
"petstore_auth": {
"type": "oauth2",
"flows": {
"implicit": {
"authorizationUrl": "https://example.org/api/oauth/dialog",
"scopes": {
"write:pets": "modify pets in your account",
"read:pets": "read your pets"
}
}
}
}
}
}
```
```yaml
components:
schemas:
GeneralError:
type: object
properties:
code:
type: integer
format: int32
message:
type: string
Category:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
Tag:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
parameters:
skipParam:
name: skip
in: query
description: number of items to skip
required: true
schema:
type: integer
format: int32
limitParam:
name: limit
in: query
description: max records to return
required: true
schema:
type: integer
format: int32
responses:
NotFound:
description: Entity not found.
IllegalInput:
description: Illegal input for operation.
GeneralError:
description: General Error
content:
application/json:
schema:
$ref: '#/components/schemas/GeneralError'
securitySchemes:
api_key:
type: apiKey
name: api-key
in: header
petstore_auth:
type: oauth2
flows:
implicit:
authorizationUrl: https://example.org/api/oauth/dialog
scopes:
write:pets: modify pets in your account
read:pets: read your pets
```
#### Paths Object
Holds the relative paths to the individual endpoints and their operations.
The path is appended to the URL from the [Server Object](#server-object) in order to construct the full URL. The Paths Object MAY be empty, due to [Access Control List (ACL) constraints](#security-filtering).
##### Patterned Fields
| Field Pattern | Type | Description |
| ---- | :----: | ---- |
| /{path} | [Path Item Object](#path-item-object) | A relative path to an individual endpoint. The field name MUST begin with a forward slash (`/`). The path is **appended** (no relative URL resolution) to the expanded URL from the [Server Object](#server-object)'s `url` field in order to construct the full URL. [Path templating](#path-templating) is allowed. When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it's up to the tooling to decide which one to use. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Path Templating Matching
Assuming the following paths, the concrete definition, `/pets/mine`, will be matched first if used:
```text
/pets/{petId}
/pets/mine
```
The following paths are considered identical and invalid:
```text
/pets/{petId}
/pets/{name}
```
The following may lead to ambiguous resolution:
```text
/{entity}/me
/books/{id}
```
##### Paths Object Example
```json
{
"/pets": {
"get": {
"description": "Returns all pets from the system that the user has access to",
"responses": {
"200": {
"description": "A list of pets.",
"content": {
"application/json": {
"schema": {
"type": "array",
"items": {
"$ref": "#/components/schemas/pet"
}
}
}
}
}
}
}
}
}
```
```yaml
/pets:
get:
description: Returns all pets from the system that the user has access to
responses:
'200':
description: A list of pets.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/pet'
```
#### Path Item Object
Describes the operations available on a single path.
A Path Item MAY be empty, due to [ACL constraints](#security-filtering).
The path itself is still exposed to the documentation viewer but they will not know which operations and parameters are available.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| $ref | `string` | Allows for a referenced definition of this path item. The value MUST be in the form of a URI, and the referenced structure MUST be in the form of a [Path Item Object](#path-item-object). In case a Path Item Object field appears both in the defined object and the referenced object, the behavior is undefined. See the rules for resolving [Relative References](#relative-references-in-api-description-uris). form‑urlencoded |
| [RFC1866](https://datatracker.ietf.org/doc/html/rfc1866#section-8.2.1) | 11/1995 | content-based serialization | [[RFC1738]] | obsoleted by [[HTML401]] [Section 17.13.4.1](https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1), [[URL]] [Section 5](https://url.spec.whatwg.org/#urlencoded-serializing) |
Style-based serialization is used in the [Parameter Object](#parameter-object) when `schema` is present, and in the [Encoding Object](#encoding-object) when at least one of `style`, `explode`, or `allowReserved` is present.
See [Appendix C](#appendix-c-using-rfc6570-based-serialization) for more details of RFC6570's two different approaches to percent-encoding, including an example involving `+`.
Content-based serialization is defined by the [Media Type Object](#media-type-object), and used with the [Parameter Object](#parameter-object) when the `content` field is present, and with the [Encoding Object](#encoding-object) based on the `contentType` field when the fields `style`, `explode`, and `allowReserved` are absent.
Each part is encoded based on the media type (e.g. `text/plain` or `application/json`), and must then be percent-encoded for use in a `form-urlencoded` string.
Note that content-based serialization for `form-data` does not expect or require percent-encoding in the data, only in per-part header values.
#### Interoperability with Historical Specifications
In most cases, generating query strings in strict compliance with [[RFC3986]] is sufficient to pass validation (including JSON Schema's `format: "uri"` and `format: "uri-reference"`), but some `form-urlencoded` implementations still expect the slightly more restrictive [[RFC1738]] rules to be used.
Since all RFC1738-compliant URIs are compliant with RFC3986, applications needing to ensure historical interoperability SHOULD use RFC1738's rules.
#### Interoperability with Web Browser Environments
WHATWG is a [web browser-oriented](https://whatwg.org/faq#what-is-the-whatwg-working-on) standards group that has defined a "URL Living Standard" for parsing and serializing URLs in a browser context, including parsing and serializing `form-urlencoded` data.
WHATWG's percent-encoding rules for query strings are different depending on whether the query string is [being treated as `form-urlencoded`](https://url.spec.whatwg.org/#application-x-www-form-urlencoded-percent-encode-set) (where it requires more percent-encoding than [[RFC1738]]) or [as part of the generic syntax](https://url.spec.whatwg.org/#query-percent-encode-set), where it allows characters that [[RFC3986]] forbids.
Implementations needing maximum compatibility with web browsers SHOULD use WHATWG's `form-urlencoded` percent-encoding rules.
However, they SHOULD NOT rely on WHATWG's less stringent generic query string rules, as the resulting URLs would fail RFC3986 validation, including JSON Schema's `format: uri` and `format: uri-reference`.
### Decoding URIs and `form-urlencoded` Strings
The percent-decoding algorithm does not care which characters were or were not percent-decoded, which means that URIs percent-encoded according to any specification will be decoded correctly.
Similarly, all `form-urlencoded` decoding algorithms simply add `+`-for-space handling to the percent-decoding algorithm, and will work regardless of the encoding specification used.
However, care must be taken to use `form-urlencoded` decoding if `+` represents a space, and to use regular percent-decoding if `+` represents itself as a literal value.
### Percent-Encoding and Illegal or Reserved Delimiters
The `[`, `]`, `|`, and space characters, which are used as delimiters for the `deepObject`, `pipeDelimited`, and `spaceDelimited` styles, respectively, all MUST be percent-encoded to comply with [[RFC3986]].
This requires users to pre-encode the character(s) in some other way in parameter names and values to distinguish them from the delimiter usage when using one of these styles.
The space character is always illegal and encoded in some way by all implementations of all versions of the relevant standards.
While one could use the `form-urlencoded` convention of `+` to distinguish spaces in parameter names and values from `spaceDelimited` delimiters encoded as `%20`, the specifications define the decoding as a single pass, making it impossible to distinguish the different usages in the decoded result.
Some environments use `[`, `]`, and possibly `|` unencoded in query strings without apparent difficulties, and WHATWG's generic query string rules do not require percent-encoding them.
Code that relies on leaving these delimiters unencoded, while using regular percent-encoding for them within names and values, is not guaranteed to be interoperable across all implementations.
For maximum interoperability, it is RECOMMENDED to either define and document an additional escape convention while percent-encoding the delimiters for these styles, or to avoid these styles entirely.
The exact method of additional encoding/escaping is left to the API designer, and is expected to be performed before serialization and encoding described in this specification, and reversed after this specification's encoding and serialization steps are reversed.
This keeps it outside of the processes governed by this specification.
## Appendix F: Resolving Security Requirements in a Referenced Document
This appendix shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. See [Resolving Implicit Connections](#resolving-implicit-connections) for more information.
First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document:
```HTTP
GET /api/description/openapi HTTP/1.1
Host: www.example.com
Accept: application/openapi+json
```
```json
"components": {
"securitySchemes": {
"MySecurity": {
"type": "http",
"scheme": "bearer",
"bearerFormat": "JWT"
}
}
},
"paths": {
"/foo": {
"$ref": "other#/components/pathItems/Foo"
}
}
```
```HTTP
GET /api/description/openapi HTTP/1.1
Host: www.example.com
Accept: application/openapi+yaml
```
```yaml
components:
securitySchemes:
MySecurity:
type: http
scheme: bearer
bearerFormat: JWT
paths:
/foo:
$ref: 'other#/components/pathItems/Foo'
```
This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available:
```HTTP
GET /api/description/other HTTP/1.1
Host: www.example.com
Accept: application/openapi+json
```
```json
"components": {
"securitySchemes": {
"MySecurity": {
"type": "http",
"scheme": "basic"
}
},
"pathItems": {
"Foo": {
"get": {
"security": [
"MySecurity": []
]
}
}
}
}
```
```HTTP
GET /api/description/other HTTP/1.1
Host: www.example.com
Accept: application/openapi+yaml
```
```yaml
components:
securitySchemes:
MySecurity:
type: http
scheme: basic
pathItems:
Foo:
get:
security:
- MySecurity: []
```
In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior). However, documented in that section, it is RECOMMENDED that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported.
OpenAPI-Specification-3.2.1/versions/3.1.2-editors.md 0000664 0000000 0000000 00000001640 15250560344 0022035 0 ustar 00root root 0000000 0000000 # OpenAPI Specification Editors
## Active
* Henry Andrews [@handrews](https://github.com/handrews)
* Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc)
* Karen Etheridge [@karenetheridge](https://github.com/karenetheridge)
* Lorna Mitchell [@lornajane](https://github.com/lornajane)
* Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh)
* Miguel Quintero [@miqui](https://github.com/miqui)
* Mike Kistler [@mikekistler](https://github.com/mikekistler)
* Ralf Handl [@ralfhandl](https://github.com/ralfhandl)
* Vincent Biret [@baywet](https://github.com/baywet)
## Emeritus
* Ron Ratovsky [@webron](https://github.com/webron)
* Darrel Miller [@darrelmiller](https://github.com/darrelmiller)
* Mike Ralphson [@MikeRalphson](https://github.com/MikeRalphson)
* Uri Sarid [@usarid](https://github.com/usarid)
* Jason Harmon [@jharmn](https://github.com/jharmn)
* Tony Tam [@fehguy](https://github.com/fehguy)
OpenAPI-Specification-3.2.1/versions/3.1.2.md 0000664 0000000 0000000 00000661301 15250560344 0020374 0 ustar 00root root 0000000 0000000 # OpenAPI Specification
## Version 3.1.2
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](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
## Introduction
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
An OpenAPI Description can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
For examples of OpenAPI usage and additional documentation, please visit [[?OpenAPI-Learn]].
For extension registries and other specifications published by the OpenAPI Initiative, as well as the authoritative rendering of this specification, please visit [spec.openapis.org](https://spec.openapis.org/).
## Definitions
### OpenAPI Description
An OpenAPI Description (OAD) formally describes the surface of an API and its semantics. It is composed of an [entry document](#openapi-description-structure), which must be an OpenAPI Document, and any/all of its referenced documents. An OAD uses and conforms to the OpenAPI Specification, and MUST contain at least one [paths](#paths-object) field, [components](#oas-components) field, or [webhooks](#oas-webhooks) field.
### OpenAPI Document
An OpenAPI Document is a single JSON or YAML document that conforms to the OpenAPI Specification. An OpenAPI Document compatible with OAS 3.\*.\* contains a required [`openapi`](#oas-version) field which designates the version of the OAS that it uses.
### Schema
A "schema" is a formal description of syntax and structure.
This document serves as the [schema](#schema) for the OpenAPI Specification format; a non-authoritative JSON Schema based on this document is also provided on [spec.openapis.org](https://spec.openapis.org) for informational purposes.
This specification also _uses_ schemas in the form of the [Schema Object](#schema-object).
### Object
When capitalized, the word "Object" refers to any of the Objects that are named by section headings in this document.
### Path Templating
Path templating refers to the usage of template expressions, delimited by curly braces (`{}`), to mark a section of a URL path as replaceable using path parameters.
Each template expression in the path MUST correspond to a path parameter that is included in the [Path Item](#path-item-object) itself and/or in each of the Path Item's [Operations](#operation-object). An exception is if the path item is empty, for example due to ACL constraints, matching path parameters are not required.
The value for these path parameters MUST NOT contain any unescaped "generic syntax" characters described by [RFC3986](https://tools.ietf.org/html/rfc3986#section-3): forward slashes (`/`), question marks (`?`), or hashes (`#`).
See [URL Percent-Encoding](#url-percent-encoding) for additional guidance on escaping characters.
### Media Types
Media type definitions are spread across several resources.
The media type definitions SHOULD be in compliance with [RFC6838](https://tools.ietf.org/html/rfc6838).
Some examples of possible media type definitions:
```text
text/plain; charset=utf-8
application/json
application/vnd.github+json
application/vnd.github.v3+json
application/vnd.github.v3.raw+json
application/vnd.github.v3.text+json
application/vnd.github.v3.html+json
application/vnd.github.v3.full+json
application/vnd.github.v3.diff
application/vnd.github.v3.patch
```
### HTTP Status Codes
The HTTP Status Codes are used to indicate the status of the executed operation.
Status codes SHOULD be selected from the available status codes registered in the [IANA Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml).
### Case Sensitivity
As most field names and values in the OpenAPI Specification are case-sensitive, this document endeavors to call out any case-insensitive names and values.
However, the case sensitivity of field names and values that map directly to HTTP concepts follow the case sensitivity rules of HTTP, even if this document does not make a note of every concept.
### Undefined and Implementation-Defined Behavior
This specification deems certain situations to have either _undefined_ or _implementation-defined_ behavior.
Behavior described as _undefined_ is likely, at least in some circumstances, to result in outcomes that contradict the specification.
This description is used when detecting the contradiction is impossible or impractical.
Implementations MAY support undefined scenarios for historical reasons, including ambiguous text in prior versions of the specification.
This support might produce correct outcomes in many cases, but relying on it is NOT RECOMMENDED as there is no guarantee that it will work across all tools or with future specification versions, even if those versions are otherwise strictly compatible with this one.
Behavior described as _implementation-defined_ allows implementations to choose which of several different-but-compliant approaches to a requirement to implement.
This documents ambiguous requirements that API description authors are RECOMMENDED to avoid in order to maximize interoperability.
Unlike undefined behavior, it is safe to rely on implementation-defined behavior if _and only if_ it can be guaranteed that all relevant tools support the same behavior.
## Specification
### Versions
The OpenAPI Specification is versioned using a `major`.`minor`.`patch` versioning scheme. The `major`.`minor` portion of the version string (for example `3.1`) SHALL designate the OAS feature set. _`.patch`_ versions address errors in, or provide clarifications to, this document, not the feature set. Tooling which supports OAS 3.1 SHOULD be compatible with all OAS 3.1.\* versions. The patch version SHOULD NOT be considered by tooling, making no distinction between `3.1.0` and `3.1.1` for example.
Occasionally, non-backwards compatible changes may be made in `minor` versions of the OAS where impact is believed to be low relative to the benefit provided.
### Format
An OpenAPI Document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or YAML format.
For example, if a field has an array value, the JSON array representation will be used:
```json
{
"field": [1, 2, 3]
}
```
All field names in the specification are **case sensitive**.
This includes all fields that are used as keys in a map, except where explicitly noted that keys are **case insensitive**.
The [schema](#schema) exposes two types of fields: _fixed fields_, which have a declared name, and _patterned fields_, which have a declared pattern for the field name.
Patterned fields MUST have unique names within the containing object.
In order to preserve the ability to round-trip between YAML and JSON formats, YAML version [1.2](https://yaml.org/spec/1.2/spec.html) is RECOMMENDED along with some additional constraints:
* Tags MUST be limited to those allowed by [YAML's JSON schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231), which defines a subset of the YAML syntax and is unrelated to [[JSON-Schema-2020-12|JSON Schema]].
* Keys used in YAML maps MUST be limited to a scalar string, as defined by the [YAML Failsafe schema ruleset](https://yaml.org/spec/1.2/spec.html#id2802346).
**Note:** While APIs may be described by OpenAPI Descriptions in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.
### OpenAPI Description Structure
An OpenAPI Description (OAD) MAY be made up of a single JSON or YAML document or be divided into multiple, connected parts at the discretion of the author. In the latter case, [Reference Object](#reference-object), [Path Item Object](#path-item-object) and [Schema Object](#schema-object) `$ref` fields, as well as the [Link Object](#link-object) `operationRef` field, and the URI form of the [Discriminator Object](#discriminator-object) `mapping` field, are used to identify the referenced elements.
In a multi-document OAD, the document containing the OpenAPI Object where parsing begins is known as that OAD's **entry document**.
It is RECOMMENDED that the entry document of an OAD be named: `openapi.json` or `openapi.yaml`.
#### Parsing Documents
In order to properly handle [Schema Objects](#schema-object), OAS 3.1 inherits the parsing requirements of [JSON Schema Specification Draft 2020-12](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-9), with appropriate modifications regarding base URIs as specified in [Relative References In URIs](#relative-references-in-api-description-uris).
This includes a requirement to parse complete documents before deeming a Schema Object reference to be unresolvable, in order to detect keywords that might provide the reference target or impact the determination of the appropriate base URI.
Implementations MAY support complete-document parsing in any of the following ways:
* Detecting OpenAPI or JSON Schema documents using media types
* Detecting OpenAPI documents through the root `openapi` field
* Detecting JSON Schema documents through detecting keywords or otherwise successfully parsing the document in accordance with the JSON Schema specification
* Detecting a document containing a referenceable Object at its root based on the expected type of the reference
* Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object
Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target.
In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results.
While some implementations support this sort of parsing due to the requirements of past versions of this specification, in version 3.1, the result of parsing fragments in isolation is _undefined_ and likely to contradict the requirements of this specification.
While it is possible to structure certain OpenAPI Descriptions to ensure that they will behave correctly when references are parsed as isolated fragments, depending on this is NOT RECOMMENDED.
This specification does not explicitly enumerate the conditions under which such behavior is safe and provides no guarantee for continued safety in any future versions of the OAS.
A special case of parsing fragments of OAS content would be if such fragments are embedded in another format, referred to as an _embedding format_ with respect to the OAS.
Note that the OAS itself is an embedding format with respect to JSON Schema, which is embedded as Schema Objects.
It is the responsibility of an embedding format to define how to parse embedded content, and OAS implementations that do not document support for an embedding format cannot be expected to parse embedded OAS content correctly.
#### Structural Interoperability
JSON or YAML objects within an OAD are interpreted as specific Objects (such as [Operation Objects](#operation-object), [Response Objects](#response-object), [Reference Objects](#reference-object), etc.) based on their context. Depending on how references are arranged, a given JSON or YAML object can be interpreted in multiple different contexts:
* As the root object of the [entry document](#openapi-description-structure), which is always interpreted as an OpenAPI Object
* As the Object type implied by its parent Object within the document
* As a reference target, with the Object type matching the reference source's context
If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as _different_ Object types, the resulting behavior is _implementation defined_, and MAY be treated as an error if detected. An example would be referencing an empty Schema Object under `#/components/schemas` where a Path Item Object is expected, as an empty object is valid for both types. For maximum interoperability, it is RECOMMENDED that OpenAPI Description authors avoid such scenarios.
#### Resolving Implicit Connections
Several features of this specification require resolution of non-URI-based connections to some other part of the OpenAPI Description (OAD).
These connections are unambiguously resolved in single-document OADs, but the resolution process in multi-document OADs is _implementation-defined_, within the constraints described in this section.
In some cases, an unambiguous URI-based alternative is available, and OAD authors are RECOMMENDED to always use the alternative:
| Source | Target | Alternative |
| ---- | ---- | ---- |
| [Security Requirement Object](#security-requirement-object) `{name}` | [Security Scheme Object](#security-scheme-object) name under the [Components Object](#components-object) | _n/a_ |
| [Discriminator Object](#discriminator-object) `mapping` _(implicit, or explicit name syntax)_ | [Schema Object](#schema-object) name under the Components Object | `mapping` _(explicit URI syntax)_ |
| [Operation Object](#operation-object) `tags` | [Tag Object](#tag-object) `name` (in the [OpenAPI Object](#openapi-object)'s `tags` array) | _n/a_ |
| [Link Object](#link-object) `operationId` | [Operation Object](#operation-object) `operationId` | `operationRef` |
A fifth implicit connection involves appending the templated URL paths of the [Paths Object](#paths-object) to the appropriate [Server Object](#server-object)'s `url` field.
This is unambiguous because only the entry document's Paths Object contributes URLs to the described API.
It is RECOMMENDED to consider all Operation Objects from all parsed documents when resolving any Link Object `operationId`.
This requires parsing all referenced documents prior to determining an `operationId` to be unresolvable.
The implicit connections in the Security Requirement Object and Discriminator Object rely on the _component name_, which is the name of the property holding the component in the appropriately typed sub-object of the Components Object.
For example, the component name of the Schema Object at `#/components/schemas/Foo` is `Foo`.
The implicit connection of `tags` in the Operation Object uses the `name` field of Tag Objects, which (like the Components Object) are found under the root OpenAPI Object.
This means resolving component names and tag names both depend on starting from the correct OpenAPI Object.
For resolving component and tag name connections from a referenced (non-entry) document, it is RECOMMENDED that tools resolve from the entry document, rather than the current document.
This allows Security Scheme Objects and Tag Objects to be defined next to the API's deployment information (the top-level array of Server Objects), and treated as an interface for referenced documents to access.
The interface approach can also work for Discriminator Objects and Schema Objects, but it is also possible to keep the Discriminator Object's behavior within a single document using the relative URI-reference syntax of `mapping`.
There are no URI-based alternatives for the Security Requirement Object or for the Operation Object's `tags` field.
These limitations are expected to be addressed in a future release.
See [Appendix F: Resolving Security Requirements in a Referenced Document](#appendix-f-resolving-security-requirements-in-a-referenced-document) for an example of the possible resolutions, including which one is recommended by this section.
The behavior for Discriminator Object non-URI mappings and for the Operation Object's `tags` field operate on the same principles.
Note that no aspect of implicit connection resolution changes how [URIs are resolved](#relative-references-in-api-description-uris), or restricts their possible targets.
### Data Types
Data types in the OAS are based on the types defined by the [JSON Schema Validation Specification Draft 2020-12](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.1.1):
"null", "boolean", "object", "array", "number", "string", or "integer".
Models are defined using the [Schema Object](#schema-object), which is a superset of the JSON Schema Specification Draft 2020-12.
JSON Schema keywords and `format` values operate on JSON "instances" which may be one of the six JSON data types, "null", "boolean", "object", "array", "number", or "string", with certain keywords and formats only applying to a specific type. For example, the `pattern` keyword and the `date-time` format only apply to strings, and treat any instance of the other five types as _automatically valid._ This means JSON Schema keywords and formats do **NOT** implicitly require the expected type. Use the `type` keyword to explicitly constrain the type.
Note that the `type` keyword allows `"integer"` as a value for convenience, but keyword and format applicability does not recognize integers as being of a distinct JSON type from other numbers because [[RFC7159|JSON]] itself does not make that distinction. Since there is no distinct JSON integer type, JSON Schema defines integers mathematically. This means that both `1` and `1.0` are [equivalent](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-4.2.2), and are both considered to be integers.
#### Data Type Format
As defined by the [JSON Schema Validation specification](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier keyword: `format`. As described in that specification, `format` is treated as a non-validating annotation by default; the ability to validate `format` varies across implementations.
The OpenAPI Initiative also hosts a [Format Registry](https://spec.openapis.org/registry/format/) for formats defined by OAS users and other specifications. Support for any registered format is strictly OPTIONAL, and support for one registered format does not imply support for any others.
Types that are not accompanied by a `format` keyword follow the type definition in the JSON Schema. Tools that do not recognize a specific `format` MAY default back to the `type` alone, as if the `format` is not specified.
For the purpose of [JSON Schema validation](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.1), each format should specify the set of JSON data types for which it applies. In this registry, these types are shown in the "JSON Data Type" column.
The formats defined by the OAS are:
| `format` | JSON Data Type | Comments |
| ---- | ---- | ---- |
| `int32` | number | signed 32 bits |
| `int64` | number | signed 64 bits (a.k.a long) |
| `float` | number | |
| `double` | number | |
| `password` | string | A hint to obscure the value. |
As noted under [Data Type](#data-types), both `type: number` and `type: integer` are considered to be numbers in the data model.
#### Working with Binary Data
The OAS can describe either _raw_ or _encoded_ binary data.
* **raw binary** is used where unencoded binary data is allowed, such as when sending a binary payload as the entire HTTP message body, or as part of a `multipart/*` payload that allows binary parts
* **encoded binary** is used where binary data is embedded in a text-only format such as `application/json` or `application/x-www-form-urlencoded` (either as a message body or in the URL query string).
In the following table showing how to use Schema Object keywords for binary data, we use `image/png` as an example binary media type. Any binary media type, including `application/octet-stream`, is sufficient to indicate binary content.
| Keyword | Raw | Encoded | Comments |
| ---- | ---- | ---- | ---- |
| `type` | _omit_ | `string` | raw binary is [outside of `type`](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-4.2.3) |
| `contentMediaType` | `image/png` | `image/png` | can sometimes be omitted if redundant (see below) |
| `contentEncoding` | _omit_ | `base64` or `base64url` | other encodings are [allowed](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8.3) |
Note that the encoding indicated by `contentEncoding`, which inflates the size of data in order to represent it as 7-bit ASCII text, is unrelated to HTTP's `Content-Encoding` header, which indicates whether and how a message body has been compressed and is applied after all content serialization described in this section has occurred. Since HTTP allows unencoded binary message bodies, there is no standardized HTTP header for indicating base64 or similar encoding of an entire message body.
Using a `contentEncoding` of `base64url` ensures that URL encoding (as required in the query string and in message bodies of type `application/x-www-form-urlencoded`) does not need to further encode any part of the already-encoded binary data.
The `contentMediaType` keyword is redundant if the media type is already set:
* as the key for a [MediaType Object](#media-type-object)
* in the `contentType` field of an [Encoding Object](#encoding-object)
If the [Schema Object](#schema-object) will be processed by a non-OAS-aware JSON Schema implementation, it may be useful to include `contentMediaType` even if it is redundant. However, if `contentMediaType` contradicts a relevant Media Type Object or Encoding Object, then `contentMediaType` SHALL be ignored.
The `maxLength` keyword MAY be used to set an expected upper bound on the length of a streaming payload. The keyword can be applied to either string data, including encoded binary data, or to unencoded binary data. For unencoded binary, the length is the number of octets.
##### Migrating binary descriptions from OAS 3.0
The following table shows how to migrate from OAS 3.0 binary data descriptions, continuing to use `image/png` as the example binary media type:
| OAS < 3.1 | OAS 3.1 | Comments |
| ---- | ---- | ---- |
| type: stringformat: binary | contentMediaType: image/png | if redundant, can be omitted, often resulting in an empty [Schema Object](#schema-object) |
| type: stringformat: byte | type: stringcontentMediaType: image/pngcontentEncoding: base64 | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe |
### Rich Text Formatting
Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting.
Where OpenAPI tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [CommonMark 0.27](https://spec.commonmark.org/0.27/). Tooling MAY choose to ignore some CommonMark or extension features to address security concerns.
While the framing of CommonMark 0.27 as a minimum requirement means that tooling MAY choose to implement extensions on top of it, note that any such extensions are by definition implementation-defined and will not be interoperable.
OpenAPI Description authors SHOULD consider how text using such extensions will be rendered by tools that offer only the minimum support.
### Relative References in API Description URIs
URIs used as references within an OpenAPI Description, or to external documentation or other supplementary information such as a license, are resolved as _identifiers_, and described by this specification as **_URIs_**.
As noted under [Parsing Documents](#parsing-documents), this specification inherits JSON Schema Specification Draft 2020-12's requirements for [loading documents](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-9) and associating them with their expected URIs, which might not match their current location.
This feature is used both for working in development or test environments without having to change the URIs, and for working within restrictive network configurations or security policies.
Note that some URI fields are named `url` for historical reasons, but the descriptive text for those fields uses the correct "URI" terminology.
Unless specified otherwise, all fields that are URIs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Relative references in [Schema Objects](#schema-object), including any that appear as `$id` values, use the nearest parent `$id` as a Base URI, as described by [JSON Schema Specification Draft 2020-12](https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2).
Relative URI references in other Objects, and in Schema Objects where no parent schema contains an `$id`, MUST be resolved using the referring document's base URI, which is determined in accordance with [[RFC3986]] [Section 5.1.2 – 5.1.4](https://tools.ietf.org/html/rfc3986#section-5.1.2).
In practice, this is usually the retrieval URI of the document, which MAY be determined based on either its current actual location or a user-supplied expected location.
If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document. If the representation of the referenced document is JSON or YAML, then the fragment identifier SHOULD be interpreted as a JSON-Pointer as per [RFC6901](https://tools.ietf.org/html/rfc6901).
Relative references in CommonMark hyperlinks are resolved in their rendered context, which might differ from the context of the API description.
### Relative References in API URLs
API endpoints are by definition accessed as locations, and are described by this specification as **_URLs_**.
Unless specified otherwise, all fields that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Unless specified otherwise, relative references are resolved using the URLs defined in the [Server Object](#server-object) as a Base URL. Note that these themselves MAY be relative to the referring document.
### Schema
This section describes the structure of the OpenAPI Description format.
This text is the only normative description of the format.
A JSON Schema is hosted on [spec.openapis.org](https://spec.openapis.org) for informational purposes.
If the JSON Schema differs from this section, then this section MUST be considered authoritative.
In the following description, if a field is not explicitly **REQUIRED** or described with a MUST or SHALL, it can be considered OPTIONAL.
#### OpenAPI Object
This is the root object of the [OpenAPI Description](#openapi-description).
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI Document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI Document. This is _not_ related to the [`info.version`](#info-version) string, which is the version of the OpenAPI Document. |
| info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required. |
| jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI. |
| servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` field is not provided, or is an empty array, the default value would be a [Server Object](#server-object) with a [url](#server-url) value of `/`. |
| paths | [Paths Object](#paths-object) | The available paths and operations for the API. |
| webhooks | Map[`string`, [Path Item Object](#path-item-object)] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](https://learn.openapis.org/examples/v3.1/webhook-example.html) is available. |
| components | [Components Object](#components-object) | An element to hold various Objects for the OpenAPI Description. |
| security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. The list can be incomplete, up to being empty or absent. To make security explicitly optional, an empty security requirement (`{}`) can be included in the array. |
| tags | [[Tag Object](#tag-object)] | A list of tags used by the OpenAPI Description with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique. |
| externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Info Object
The object provides metadata about the API.
The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| title | `string` | **REQUIRED**. The title of the API. |
| summary | `string` | A short summary of the API. |
| description | `string` | A description of the API. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
| termsOfService | `string` | A URI for the Terms of Service for the API. This MUST be in the form of a URI. |
| contact | [Contact Object](#contact-object) | The contact information for the exposed API. |
| license | [License Object](#license-object) | The license information for the exposed API. |
| version | `string` | **REQUIRED**. The version of the OpenAPI Document (which is distinct from the [OpenAPI Specification version](#oas-version) or the version of the API being described or the version of the OpenAPI Description). |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Info Object Example
```json
{
"title": "Example Pet Store App",
"summary": "A pet store manager.",
"description": "This is an example server for a pet store.",
"termsOfService": "https://example.com/terms/",
"contact": {
"name": "API Support",
"url": "https://www.example.com/support",
"email": "support@example.com"
},
"license": {
"name": "Apache 2.0",
"url": "https://www.apache.org/licenses/LICENSE-2.0.html"
},
"version": "1.0.1"
}
```
```yaml
title: Example Pet Store App
summary: A pet store manager.
description: This is an example server for a pet store.
termsOfService: https://example.com/terms/
contact:
name: API Support
url: https://www.example.com/support
email: support@example.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.1
```
#### Contact Object
Contact information for the exposed API.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| name | `string` | The identifying name of the contact person/organization. |
| url | `string` | The URI for the contact information. This MUST be in the form of a URI. |
| email | `string` | The email address of the contact person/organization. This MUST be in the form of an email address. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Contact Object Example
```json
{
"name": "API Support",
"url": "https://www.example.com/support",
"email": "support@example.com"
}
```
```yaml
name: API Support
url: https://www.example.com/support
email: support@example.com
```
#### License Object
License information for the exposed API.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| name | `string` | **REQUIRED**. The license name used for the API. |
| identifier | `string` | An [SPDX](https://spdx.org/licenses/) license expression for the API. The `identifier` field is mutually exclusive of the `url` field. |
| url | `string` | A URI for the license used for the API. This MUST be in the form of a URI. The `url` field is mutually exclusive of the `identifier` field. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### License Object Example
```json
{
"name": "Apache 2.0",
"identifier": "Apache-2.0"
}
```
```yaml
name: Apache 2.0
identifier: Apache-2.0
```
#### Server Object
An object representing a Server.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the document containing the Server Object is being served. Query and fragment MUST NOT be part of this URL. Variable substitutions will be made when a variable is named in `{`braces`}`. |
| description | `string` | An optional string describing the host designated by the URL. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
| variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is used for substitution in the server's URL template. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Server Object Example
A single server would be described as:
```json
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
}
```
```yaml
url: https://development.gigantic-server.com/v1
description: Development server
```
The following shows how multiple servers can be described, for example, at the OpenAPI Object's [`servers`](#oas-servers):
```json
{
"servers": [
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
},
{
"url": "https://staging.gigantic-server.com/v1",
"description": "Staging server"
},
{
"url": "https://api.gigantic-server.com/v1",
"description": "Production server"
}
]
}
```
```yaml
servers:
- url: https://development.gigantic-server.com/v1
description: Development server
- url: https://staging.gigantic-server.com/v1
description: Staging server
- url: https://api.gigantic-server.com/v1
description: Production server
```
The following shows how variables can be used for a server configuration:
```json
{
"servers": [
{
"url": "https://{username}.gigantic-server.com:{port}/{basePath}",
"description": "The production API server",
"variables": {
"username": {
"default": "demo",
"description": "A user-specific subdomain. Use `demo` for a free sandbox environment."
},
"port": {
"enum": ["8443", "443"],
"default": "8443"
},
"basePath": {
"default": "v2"
}
}
}
]
}
```
```yaml
servers:
- url: https://{username}.gigantic-server.com:{port}/{basePath}
description: The production API server
variables:
username:
# note! no enum here means it is an open value
default: demo
description: A user-specific subdomain. Use `demo` for a free sandbox environment.
port:
enum:
- '8443'
- '443'
default: '8443'
basePath:
# open meaning there is the opportunity to use special base paths as assigned by the provider, default is "v2"
default: v2
```
#### Server Variable Object
An object representing a Server Variable for server URL template substitution.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array MUST NOT be empty. |
| default | `string` | **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. If the [`enum`](#server-variable-enum) is defined, the value MUST exist in the enum's values. Note that this behavior is different from the [Schema Object](#schema-object)'s `default` keyword, which documents the receiver's behavior rather than inserting the value into the data. |
| description | `string` | An optional description for the server variable. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Components Object
Holds a set of reusable objects for different aspects of the OAS.
All objects defined within the Components Object will have no effect on the API unless they are explicitly referenced from outside the Components Object.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :---- | ---- |
| schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object). |
| responses | Map[`string`, [Response Object](#response-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Response Objects](#response-object). |
| parameters | Map[`string`, [Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Parameter Objects](#parameter-object). |
| examples | Map[`string`, [Example Object](#example-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Example Objects](#example-object). |
| requestBodies | Map[`string`, [Request Body Object](#request-body-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Request Body Objects](#request-body-object). |
| headers | Map[`string`, [Header Object](#header-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Header Objects](#header-object). |
| securitySchemes | Map[`string`, [Security Scheme Object](#security-scheme-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Security Scheme Objects](#security-scheme-object). |
| links | Map[`string`, [Link Object](#link-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Link Objects](#link-object). |
| callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Callback Objects](#callback-object). |
| pathItems | Map[`string`, [Path Item Object](#path-item-object)] | An object to hold reusable [Path Item Objects](#path-item-object). |
This object MAY be extended with [Specification Extensions](#specification-extensions).
All the fixed fields declared above are objects that MUST use keys that match the regular expression: `^[a-zA-Z0-9\.\-_]+$`.
Field Name Examples:
```text
User
User_1
User_Name
user-name
my.org.User
```
##### Components Object Example
```json
"components": {
"schemas": {
"GeneralError": {
"type": "object",
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
}
}
},
"Category": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
}
}
},
"Tag": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
}
}
}
},
"parameters": {
"skipParam": {
"name": "skip",
"in": "query",
"description": "number of items to skip",
"required": true,
"schema": {
"type": "integer",
"format": "int32"
}
},
"limitParam": {
"name": "limit",
"in": "query",
"description": "max records to return",
"required": true,
"schema" : {
"type": "integer",
"format": "int32"
}
}
},
"responses": {
"NotFound": {
"description": "Entity not found."
},
"IllegalInput": {
"description": "Illegal input for operation."
},
"GeneralError": {
"description": "General Error",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/GeneralError"
}
}
}
}
},
"securitySchemes": {
"api_key": {
"type": "apiKey",
"name": "api-key",
"in": "header"
},
"petstore_auth": {
"type": "oauth2",
"flows": {
"implicit": {
"authorizationUrl": "https://example.org/api/oauth/dialog",
"scopes": {
"write:pets": "modify pets in your account",
"read:pets": "read your pets"
}
}
}
}
}
}
```
```yaml
components:
schemas:
GeneralError:
type: object
properties:
code:
type: integer
format: int32
message:
type: string
Category:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
Tag:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
parameters:
skipParam:
name: skip
in: query
description: number of items to skip
required: true
schema:
type: integer
format: int32
limitParam:
name: limit
in: query
description: max records to return
required: true
schema:
type: integer
format: int32
responses:
NotFound:
description: Entity not found.
IllegalInput:
description: Illegal input for operation.
GeneralError:
description: General Error
content:
application/json:
schema:
$ref: '#/components/schemas/GeneralError'
securitySchemes:
api_key:
type: apiKey
name: api-key
in: header
petstore_auth:
type: oauth2
flows:
implicit:
authorizationUrl: https://example.org/api/oauth/dialog
scopes:
write:pets: modify pets in your account
read:pets: read your pets
```
#### Paths Object
Holds the relative paths to the individual endpoints and their operations.
The path is appended to the URL from the [Server Object](#server-object) in order to construct the full URL. The Paths Object MAY be empty, due to [Access Control List (ACL) constraints](#security-filtering).
##### Patterned Fields
| Field Pattern | Type | Description |
| ---- | :----: | ---- |
| /{path} | [Path Item Object](#path-item-object) | A relative path to an individual endpoint. The field name MUST begin with a forward slash (`/`). The path is **appended** (no relative URL resolution) to the expanded URL from the [Server Object](#server-object)'s `url` field in order to construct the full URL. [Path templating](#path-templating) is allowed. When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it's up to the tooling to decide which one to use. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
##### Path Templating Matching
Assuming the following paths, the concrete definition, `/pets/mine`, will be matched first if used:
```text
/pets/{petId}
/pets/mine
```
The following paths are considered identical and invalid:
```text
/pets/{petId}
/pets/{name}
```
The following may lead to ambiguous resolution:
```text
/{entity}/me
/books/{id}
```
##### Paths Object Example
```json
{
"/pets": {
"get": {
"description": "Returns all pets from the system that the user has access to",
"responses": {
"200": {
"description": "A list of pets.",
"content": {
"application/json": {
"schema": {
"type": "array",
"items": {
"$ref": "#/components/schemas/pet"
}
}
}
}
}
}
}
}
}
```
```yaml
/pets:
get:
description: Returns all pets from the system that the user has access to
responses:
'200':
description: A list of pets.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/pet'
```
#### Path Item Object
Describes the operations available on a single path.
A Path Item MAY be empty, due to [ACL constraints](#security-filtering).
The path itself is still exposed to the documentation viewer but they will not know which operations and parameters are available.
##### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| $ref | `string` | Allows for a referenced definition of this path item. The value MUST be in the form of a URI, and the referenced structure MUST be in the form of a [Path Item Object](#path-item-object). In case a Path Item Object field appears both in the defined object and the referenced object, the behavior is undefined. See the rules for resolving [Relative References](#relative-references-in-api-description-uris). form‑urlencoded |
| [RFC1866](https://datatracker.ietf.org/doc/html/rfc1866#section-8.2.1) | 11/1995 | content-based serialization | [[RFC1738]] | obsoleted by [[HTML401]] [Section 17.13.4.1](https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1), [[URL]] [Section 5](https://url.spec.whatwg.org/#urlencoded-serializing) |
Style-based serialization with percent-encoding is used in the [Parameter Object](#parameter-object) when `schema` is present, and in the [Encoding Object](#encoding-object) when at least one of `style`, `explode`, or `allowReserved` is present.
See [Appendix C](#appendix-c-using-rfc6570-based-serialization) for more details of RFC6570's two different approaches to percent-encoding, including an example involving `+`.
Content-based serialization is defined by the [Media Type Object](#media-type-object), and used with the [Parameter Object](#parameter-object) and [Header Object](#header-object) when the `content` field is present, and with the [Encoding Object](#encoding-object) based on the `contentType` field when the fields `style`, `explode`, and `allowReserved` are absent.
Each part is encoded based on the media type (e.g. `text/plain` or `application/json`), and must then be percent-encoded for use in a `form-urlencoded` string unless the media type already incorporates URI percent-encoding.
#### Interoperability with Historical Specifications
In most cases, generating query strings in strict compliance with [[RFC3986]] is sufficient to pass validation (including JSON Schema's `format: "uri"` and `format: "uri-reference"` when `format` validation is enabled), but some `form-urlencoded` implementations still expect the slightly more restrictive [[RFC1738]] rules to be used.
Since all RFC1738-compliant URIs are compliant with RFC3986, applications needing to ensure historical interoperability SHOULD use RFC1738's rules.
#### Interoperability with Web Browser Environments
WHATWG is a [web browser-oriented](https://whatwg.org/faq#what-is-the-whatwg-working-on) standards group that has defined a "URL Living Standard" for parsing and serializing URLs in a browser context, including parsing and serializing `form-urlencoded` data.
WHATWG's percent-encoding rules for query strings are different depending on whether the query string is [being treated as `form-urlencoded`](https://url.spec.whatwg.org/#application-x-www-form-urlencoded-percent-encode-set) (where it requires more percent-encoding than [[RFC1738]]) or [as part of the generic syntax](https://url.spec.whatwg.org/#query-percent-encode-set), where it allows characters that [[RFC3986]] forbids.
Implementations needing maximum compatibility with web browsers SHOULD use WHATWG's `form-urlencoded` percent-encoding rules.
However, they SHOULD NOT rely on WHATWG's less stringent generic query string rules, as the resulting URLs would fail RFC3986 validation, including JSON Schema's `format: uri` and `format: uri-reference` (when `format` validation is endabled).
### Decoding URIs and `form-urlencoded` Strings
The percent-decoding algorithm does not care which characters were or were not percent-decoded, which means that URIs percent-encoded according to any specification will be decoded correctly.
Similarly, all `form-urlencoded` decoding algorithms simply add `+`-for-space handling to the percent-decoding algorithm, and will work regardless of the encoding specification used.
However, care must be taken to use `form-urlencoded` decoding if `+` represents a space, and to use regular percent-decoding if `+` represents itself as a literal value.
### Percent-Encoding and Illegal or Reserved Delimiters
The `[`, `]`, `|`, and space characters, which are used as delimiters for the `deepObject`, `pipeDelimited`, and `spaceDelimited` styles, respectively, all MUST be percent-encoded to comply with [[RFC3986]].
This requires users to pre-encode the character(s) in some other way in parameter names and values to distinguish them from the delimiter usage when using one of these styles.
The space character is always illegal and encoded in some way by all implementations of all versions of the relevant standards.
While one could use the `form-urlencoded` convention of `+` to distinguish spaces in parameter names and values from `spaceDelimited` delimiters encoded as `%20`, the specifications define the decoding as a single pass, making it impossible to distinguish the different usages in the decoded result unless a non-standard parsing algorithm is used that separates based on one delimiter before decoding the other.
Any such non-standard parsing approach will not be interoperable across all tools.
Some environments use `[`, `]`, and possibly `|` unencoded in query strings without apparent difficulties.
WHATWG's generic query string rules do not require percent-encoding them in non-`form-urlencoded` query strings, although it also excludes them from the set of valid URL Unicode code points.
Code that relies on leaving these delimiters unencoded, while using regular percent-encoding for them within names and values, is not guaranteed to be interoperable across all implementations.
For maximum interoperability, it is RECOMMENDED to either define and document an additional escape convention while percent-encoding the delimiters for these styles, or to avoid these styles entirely.
The exact method of additional encoding/escaping is left to the API designer, and is expected to be performed before serialization and encoding described in this specification, and reversed after this specification's encoding and serialization steps are reversed.
This keeps it outside of the processes governed by this specification.
## Appendix F: Resolving Security Requirements in a Referenced Document
This appendix shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. See [Resolving Implicit Connections](#resolving-implicit-connections) for more information.
First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document:
```HTTP
GET /api/description/openapi HTTP/1.1
Host: www.example.com
Accept: application/openapi+json
```
```json
"components": {
"securitySchemes": {
"MySecurity": {
"type": "http",
"scheme": "bearer",
"bearerFormat": "JWT"
}
}
},
"paths": {
"/foo": {
"$ref": "other#/components/pathItems/Foo"
}
}
```
```HTTP
GET /api/description/openapi HTTP/1.1
Host: www.example.com
Accept: application/openapi+yaml
```
```yaml
components:
securitySchemes:
MySecurity:
type: http
scheme: bearer
bearerFormat: JWT
paths:
/foo:
$ref: 'other#/components/pathItems/Foo'
```
This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available:
```HTTP
GET /api/description/other HTTP/1.1
Host: www.example.com
Accept: application/openapi+json
```
```json
"components": {
"securitySchemes": {
"MySecurity": {
"type": "http",
"scheme": "basic"
}
},
"pathItems": {
"Foo": {
"get": {
"security": [
"MySecurity": []
]
}
}
}
}
```
```HTTP
GET /api/description/other HTTP/1.1
Host: www.example.com
Accept: application/openapi+yaml
```
```yaml
components:
securitySchemes:
MySecurity:
type: http
scheme: basic
pathItems:
Foo:
get:
security:
- MySecurity: []
```
In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior). However, documented in that section, it is RECOMMENDED that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported.
OpenAPI-Specification-3.2.1/versions/3.2.0-editors.md 0000664 0000000 0000000 00000001640 15250560344 0022034 0 ustar 00root root 0000000 0000000 # OpenAPI Specification Editors
## Active
* Henry Andrews [@handrews](https://github.com/handrews)
* Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc)
* Karen Etheridge [@karenetheridge](https://github.com/karenetheridge)
* Lorna Mitchell [@lornajane](https://github.com/lornajane)
* Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh)
* Miguel Quintero [@miqui](https://github.com/miqui)
* Mike Kistler [@mikekistler](https://github.com/mikekistler)
* Ralf Handl [@ralfhandl](https://github.com/ralfhandl)
* Vincent Biret [@baywet](https://github.com/baywet)
## Emeritus
* Ron Ratovsky [@webron](https://github.com/webron)
* Darrel Miller [@darrelmiller](https://github.com/darrelmiller)
* Mike Ralphson [@MikeRalphson](https://github.com/MikeRalphson)
* Uri Sarid [@usarid](https://github.com/usarid)
* Jason Harmon [@jharmn](https://github.com/jharmn)
* Tony Tam [@fehguy](https://github.com/fehguy)
OpenAPI-Specification-3.2.1/versions/3.2.0.md 0000664 0000000 0000000 00001102524 15250560344 0020371 0 ustar 00root root 0000000 0000000 # OpenAPI Specification
## Version 3.2.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](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
## Introduction
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service by [parsing and serializing](#parsing-and-serializing) HTTP messages to and from a [data model](#data-types) with a minimal amount of implementation logic.
An [OpenAPI Description](#openapi-description-structure) (OAD) can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
For examples of OpenAPI usage and additional documentation, please visit [[?OpenAPI-Learn]].
For extension registries and other specifications published by the OpenAPI Initiative, as well as the authoritative rendering of this specification, please visit [spec.openapis.org](https://spec.openapis.org/).
### Versions and Deprecation
The OpenAPI Specification is versioned using a `major`.`minor`.`patch` versioning scheme. The `major`.`minor` portion of the version string (for example `3.1`) SHALL designate the OAS feature set. _`.patch`_ versions address errors in, or provide clarifications to, this document, not the feature set. Tooling which supports OAS 3.1 SHOULD be compatible with all OAS 3.1.\* versions. The patch version SHOULD NOT be considered by tooling, making no distinction between `3.1.0` and `3.1.1` for example.
Certain fields or features may be marked **Deprecated**.
These fields and features remain part of the specification and can be used like any other field or feature.
However, OpenAPI Description authors should use newer fields and features documented to replace the deprecated ones whenever possible.
At this time, such elements are expected to remain part of the OAS until the next major version, although a future minor version of this specification may define a policy for later removal of deprecated elements.
Occasionally, non-backwards compatible changes may be made in `minor` versions of the OAS where impact is believed to be low relative to the benefit provided.
### Undefined and Implementation-Defined Behavior
This specification deems certain situations to have either _undefined_ or _implementation-defined_ behavior.
Behavior described as _undefined_ is likely, at least in some circumstances, to result in outcomes that contradict the specification.
This description is used when detecting the contradiction is impossible or impractical.
Implementations MAY support undefined scenarios for historical reasons, including ambiguous text in prior versions of the specification.
This support might produce correct outcomes in many cases, but relying on it is NOT RECOMMENDED as there is no guarantee that it will work across all tools or with future specification versions, even if those versions are otherwise strictly compatible with this one.
Behavior described as _implementation-defined_ allows implementations to choose which of several different-but-compliant approaches to a requirement to implement.
This documents ambiguous requirements that API description authors are RECOMMENDED to avoid in order to maximize interoperability.
Unlike undefined behavior, it is safe to rely on implementation-defined behavior if _and only if_ it can be guaranteed that all relevant tools support the same behavior.
## Format
An OpenAPI document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in [[RFC8259|JSON]] or [[YAML|YAML]] format.
Examples in this specification will be shown in YAML for brevity.
All field names in the specification are **case-sensitive**.
This includes all fields that are used as keys in a map, except where explicitly noted that keys are **case-insensitive**.
OAS [Objects](#objects-and-fields) expose two types of fields: _fixed fields_, which have a declared name, and _patterned fields_, which have a declared pattern for the field name.
Patterned fields MUST have unique names within the containing object.
**Note:** While APIs may be described by OpenAPI Descriptions in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.
### JSON and YAML Compatibility
In order to preserve the ability to round-trip between YAML and JSON formats, YAML version [1.2](https://yaml.org/spec/1.2/spec.html) is RECOMMENDED along with the additional constraints listed in [[!RFC9512]] [Section 3.4](https://www.rfc-editor.org/rfc/rfc9512.html#name-yaml-and-json).
The recommendation in previous versions of this specification to restrict YAML to its "JSON" [schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231) allowed for the inclusion of certain values that (despite the name) cannot be represented in JSON.
OAD authors SHOULD NOT rely on any such JSON-incompatible YAML values.
### Case Sensitivity
As most field names and values in the OpenAPI Specification are case-sensitive, this document endeavors to call out any case-insensitive names and values.
However, the case sensitivity of field names and values that map directly to HTTP concepts follow the case sensitivity rules of HTTP, even if this document does not make a note of every concept.
### Rich Text Formatting
Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting.
Where OpenAPI tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [CommonMark 0.27](https://spec.commonmark.org/0.27/). Tooling MAY choose to ignore some CommonMark or extension features to address security concerns.
While the framing of CommonMark 0.27 as a minimum requirement means that tooling MAY choose to implement extensions on top of it, note that any such extensions are by definition implementation-defined and will not be interoperable.
OpenAPI Description authors SHOULD consider how text using such extensions will be rendered by tools that offer only the minimum support.
## Objects and Fields
This section describes the structure of the OpenAPI Description format.
This text is the only normative description of the format.
A JSON Schema is hosted on [spec.openapis.org](https://spec.openapis.org) for informational purposes.
If the JSON Schema differs from this section, then this section MUST be considered authoritative.
In the following description, if a field is not explicitly **REQUIRED** or described with a MUST or SHALL, it can be considered OPTIONAL.
### OpenAPI Object
This is the root object of the [OpenAPI Description](#openapi-description-structure).
#### Fixed Fields
In addition to the required fields, at least one of the `components`, `paths`, or `webhooks` fields MUST be present.
| Field Name | Type | Description |
| ---- | :----: | ---- |
| openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions-and-deprecation) of the OpenAPI Specification that the OpenAPI document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI document. This is _not_ related to the [`info.version`](#info-version) string, which describes the OpenAPI document's version. |
| $self | `string` | This string MUST be in the form of a URI reference as defined by [[RFC3986]] [Section 4.1](https://www.rfc-editor.org/rfc/rfc3986#section-4.1). The `$self` field provides the self-assigned URI of this document, which also serves as its base URI in accordance with [[RFC3986]] [Section 5.1.1](https://www.rfc-editor.org/rfc/rfc3986#section-5.1.1). Implementations MUST support identifying the targets of [API description URIs](#relative-references-in-api-description-uris) using the URI defined by this field when it is present. See [Establishing the Base URI](#establishing-the-base-uri) for the base URI behavior when `$self` is absent or relative, and see [Appendix F](#appendix-f-examples-of-base-uri-determination-and-reference-resolution) for examples of using `$self` to resolve references. |
| info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required. |
| jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI. |
| servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` field is not provided, or is an empty array, the default value would be an array consisting of a single [Server Object](#server-object) with a [url](#server-url) value of `/`. |
| paths | [Paths Object](#paths-object) | The available paths and operations for the API. |
| webhooks | Map[`string`, [Path Item Object](#path-item-object)] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](https://learn.openapis.org/examples/v3.1/webhook-example.html) is available. |
| components | [Components Object](#components-object) | An element to hold various Objects for the OpenAPI Description. |
| security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. The list can be incomplete, up to being empty or absent. To make security explicitly optional, an empty security requirement (`{}`) can be included in the array. |
| tags | [[Tag Object](#tag-object)] | A list of tags used by the OpenAPI Description with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique. |
| externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
To ensure interoperability, references MUST use the target document's `$self` URI if the `$self` field is present.
Implementations MAY choose to support referencing by other URIs such as the retrieval URI even when `$self` is present, however this behavior is not interoperable and relying on it is NOT RECOMMENDED.
#### OpenAPI Description Structure
An **OpenAPI Description** (**OAD**) formally describes the surface of an API and its semantics.
An OAD MAY be made up of a single document, or be distributed across multiple documents that are connected by various fields using [URI references](#relative-references-in-api-description-uris) and [implicit connections](#resolving-implicit-connections).
In order for parsing behavior to be well-defined, all documents in an OAD MUST have either an OpenAPI Object or a Schema Object at the root, and MUST be parsed as complete documents, as described in the next section.
Documents with a different Object at the root, or that mix OAD content with other content, MAY be supported, but will have implementation-defined or, potentially, undefined behavior as described in [Appendix G: Parsing and Resolution Guidance](#appendix-g-parsing-and-resolution-guidance).
Throughout this specification, documents are assumed to have either an OpenAPI Object or Schema Object at the root unless otherwise specified.
In a multi-document OAD, the document containing the OpenAPI Object where parsing begins is known as that OAD's **entry document**.
It is RECOMMENDED that the entry document of an OAD be named `openapi.json` or `openapi.yaml`.
An OpenAPI Object MAY be embedded in another format, called the **embedding format**, just as JSON Schema is embedded in the OAS in the form of Schema Objects.
It is the responsibility of an embedding format to define how to parse embedded content, and OAS implementations that do not document support for an embedding format cannot be expected to parse embedded OAS content correctly.
##### Parsing Documents
Each document in an OAD MUST be fully parsed in order to locate possible reference targets.
This includes the parsing requirements of [JSON Schema Specification Draft 2020-12](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-9), with appropriate modifications regarding base URIs as specified in [Relative References In URIs](#relative-references-in-api-description-uris).
Reference targets are defined by fields including the OpenAPI Object's [`$self`](#oas-self) field and the [Schema Object's](#schema-object) `$id`, `$anchor`, and `$dynamicAnchor` keywords.
Implementations MUST NOT treat a reference as unresolvable before completely parsing all documents provided to the implementation as possible parts of the OAD.
If only the referenced part of the document is parsed when resolving a reference, the resulting behavior can be implementation-defined or undefined; see [Warnings Regarding Fragmentary Parsing](#warnings-regarding-fragmentary-parsing) in [Appendix G](#appendix-g-parsing-and-resolution-guidance) for details.
##### Relative References in API Description URIs
URIs used as references within an OpenAPI Description, or to external documentation or other supplementary information such as a license, are resolved as _identifiers_, and described by this specification as **_URIs_**, in contrast with [API URLs](#relative-references-in-api-urls).
Note that some URI fields are named `url` for historical reasons, but the descriptive text for those fields uses the correct "URI" terminology.
As noted under [Parsing Documents](#parsing-documents), several fields can be used to associate an OpenAPI document or a Schema Object with a URI, which might not match the document's or schema's location.
This allows the same references to be used in different deployment environments, including local filesystems or networks restricted by security policies or connectivity limitations.
Unless specified otherwise, all fields that are URIs MAY be relative references as defined by [[RFC3986]] [Section 4.2](https://tools.ietf.org/html/rfc3986#section-4.2).
###### Establishing the Base URI
Relative URI references are resolved using the appropriate base URI, which MUST be determined in accordance with [[RFC3986]] [Section 5.1.1 – 5.1.4](https://tools.ietf.org/html/rfc3986#section-5.1.1) and, for Schema objects, [JSON Schema draft 2020-12 Section 8.2](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-8.2), as illustrated by the examples in [Appendix F: Examples of Base URI Determination and Reference Resolution](#appendix-f-examples-of-base-uri-determination-and-reference-resolution).
If `$self` is a relative URI reference, it is resolved against the next possible base URI source ([[RFC3986]] [Section 5.1.2 – 5.1.4](https://tools.ietf.org/html/rfc3986#section-5.1.2)) before being used for the resolution of other relative URI references.
The most common base URI source that is used in the event of a missing or relative `$self` (in the [OpenAPI Object](#openapi-object)) and (for [Schema Object](#schema-object)) `$id` is the retrieval URI.
Implementations MAY support document retrieval, although see the [Security Considerations](#security-considerations) sections for additional guidance.
Even if retrieval is supported, it may be impossible due to network configuration or server unavailability (including the server hosting an older version while a new version is in development), or undesirable due to performance impacts.
Therefore, all implementations SHOULD allow users to provide documents with their intended retrieval URIs so that references can be resolved as if retrievals were performed.
###### Resolving URI fragments
If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document. If the representation of the referenced document is JSON or YAML, then the fragment identifier SHOULD be interpreted as a JSON Pointer as per [RFC6901](https://tools.ietf.org/html/rfc6901).
###### Relative URI References in CommonMark Fields
Relative references in CommonMark hyperlinks are resolved in their rendered context, which might differ from the context of the API description.
##### Resolving Implicit Connections
Several features of this specification require resolution of non-URI-based connections to some other part of the OpenAPI Description (OAD).
These connections are unambiguously resolved in single-document OADs, but the resolution process in multi-document OADs is _implementation-defined_, within the constraints described in this section.
In some cases, an unambiguous URI-based alternative is available, and OAD authors are RECOMMENDED to use the alternative to maximize interoperability.
For resolving [Components Object](#components-object) and [Tag Object](#tag-object) names from a referenced (non-entry) document, it is RECOMMENDED that tools resolve from the entry document, rather than the current document.
For resolving an [Operation Object](#operation-object) based on an `operationId`, it is RECOMMENDED to consider all Operation Objects from all parsed documents.
Note that no aspect of implicit connection resolution changes how [URIs are resolved](#relative-references-in-api-description-uris), or restricts their possible targets.
See [Appendix G: Parsing and Resolution Guidance](#appendix-g-parsing-and-resolution-guidance) for more details, including a list of Objects and fields using implicit connections.
### Info Object
The object provides metadata about the API.
The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| title | `string` | **REQUIRED**. The title of the API. |
| summary | `string` | A short summary of the API. |
| description | `string` | A description of the API. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
| termsOfService | `string` | A URI for the Terms of Service for the API. This MUST be in the form of a URI. |
| contact | [Contact Object](#contact-object) | The contact information for the exposed API. |
| license | [License Object](#license-object) | The license information for the exposed API. |
| version | `string` | **REQUIRED**. The version of the OpenAPI document (which is distinct from the [OpenAPI Specification version](#oas-version) or the version of the API being described or the version of the OpenAPI Description). |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Info Object Example
```yaml
title: Example Pet Store App
summary: A pet store manager.
description: This is an example server for a pet store.
termsOfService: https://example.com/terms/
contact:
name: API Support
url: https://www.example.com/support
email: support@example.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
version: 1.0.1
```
### Contact Object
Contact information for the exposed API.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| name | `string` | The identifying name of the contact person/organization. |
| url | `string` | The URI for the contact information. This MUST be in the form of a URI. |
| email | `string` | The email address of the contact person/organization. This MUST be in the form of an email address. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Contact Object Example
```yaml
name: API Support
url: https://www.example.com/support
email: support@example.com
```
### License Object
License information for the exposed API.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| name | `string` | **REQUIRED**. The license name used for the API. |
| identifier | `string` | An [SPDX](https://spdx.org/licenses/) license expression for the API. The `identifier` field is mutually exclusive of the `url` field. |
| url | `string` | A URI for the license used for the API. This MUST be in the form of a URI. The `url` field is mutually exclusive of the `identifier` field. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### License Object Example
```yaml
name: Apache 2.0
identifier: Apache-2.0
```
### Server Object
An object representing a Server.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the document containing the Server Object is being served. Query and fragment MUST NOT be part of this URL. Variable substitutions will be made when a variable is named in `{`braces`}`. |
| description | `string` | An optional string describing the host designated by the URL. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
| name | `string` | An optional unique string to refer to the host designated by the URL. |
| variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is used for substitution in the server's URL template. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Relative References in API URLs
API endpoints are by definition accessed as locations, and are described by this specification as **_URLs_**.
Unless specified otherwise, all fields that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
Because the API is a distinct entity from the OpenAPI document, RFC3986's base URI rules for the OpenAPI document do not apply.
Unless specified otherwise, relative references are resolved using the URLs defined in the [Server Object](#server-object) as a base URL. Note that these themselves MAY be relative to the referring document.
##### Examples of API Base URL Determination
Assume a retrieval URI of `https://device1.example.com` for the following OpenAPI document:
```yaml
openapi: 3.2.0
$self: https://apidescriptions.example.com/foo
info:
title: Example API
version: 1.0
servers:
- url: .
description: The production API on this device
- url: ./test
description: The test API on this device
```
For API URLs the `$self` field, which identifies the OpenAPI document, is ignored and the retrieval URI is used instead. This produces a normalized production URL of `https://device1.example.com`, and a normalized test URL of `https://device1.example.com/test`.
#### Server Object Example
A single server would be described as:
```yaml
url: https://development.gigantic-server.com/v1
description: Development server
name: dev
```
The following shows how multiple servers can be described, for example, at the OpenAPI Object's [`servers`](#oas-servers):
```yaml
servers:
- url: https://development.gigantic-server.com/v1
description: Development server
name: dev
- url: https://staging.gigantic-server.com/v1
description: Staging server
name: staging
- url: https://api.gigantic-server.com/v1
description: Production server
name: prod
```
The following shows how variables can be used for a server configuration:
```yaml
servers:
- url: https://{username}.gigantic-server.com:{port}/{basePath}
description: The production API server
name: prod
variables:
username:
# note! no enum here means it is an open value
default: demo
description: A user-specific subdomain. Use `demo` for a free sandbox environment.
port:
enum:
- '8443'
- '443'
default: '8443'
basePath:
# open meaning there is the opportunity to use special base paths as assigned by the provider, default is "v2"
default: v2
```
### Server Variable Object
An object representing a Server Variable for server URL template substitution.
The server URL templating is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax.
```abnf
server-url-template = 1*( literals / server-variable )
server-variable = "{" server-variable-name "}"
server-variable-name = 1*( %x00-7A / %x7C / %x7E-10FFFF ) ; every Unicode character except { and }
literals = 1*( %x21 / %x23-24 / %x26-3B / %x3D / %x3F-5B
/ %x5D / %x5F / %x61-7A / %x7E / ucschar / iprivate
/ pct-encoded)
; any Unicode character except: CTL, SP,
; DQUOTE, "%" (aside from pct-encoded),
; "<", ">", "\", "^", "`", "{", "|", "}"
pct-encoded = "%" HEXDIG HEXDIG
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
```
Here, `literals`, `pct-encoded`, `ucschar` and `iprivate` definitions are taken from [RFC 6570](https://www.rfc-editor.org/rfc/rfc6570), incorporating the corrections specified in [Errata 6937](https://www.rfc-editor.org/errata/eid6937) for `literals`.
Each server variable MUST NOT appear more than once in the URL template.
See the [Paths Object](#paths-object) for guidance on constructing full request URLs.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array MUST NOT be empty. |
| default | `string` | **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. If the [`enum`](#server-variable-enum) is defined, the value MUST exist in the enum's values. Note that this behavior is different from the [Schema Object](#schema-object)'s `default` keyword, which documents the receiver's behavior rather than inserting the value into the data. |
| description | `string` | An optional description for the server variable. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
### Components Object
Holds a set of reusable objects for different aspects of the OAS.
All objects defined within the Components Object will have no effect on the API unless they are explicitly referenced from outside the Components Object.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :---- | ---- |
| schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object). |
| responses | Map[`string`, [Response Object](#response-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Response Objects](#response-object). |
| parameters | Map[`string`, [Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Parameter Objects](#parameter-object). |
| examples | Map[`string`, [Example Object](#example-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Example Objects](#example-object). |
| requestBodies | Map[`string`, [Request Body Object](#request-body-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Request Body Objects](#request-body-object). |
| headers | Map[`string`, [Header Object](#header-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Header Objects](#header-object). |
| securitySchemes | Map[`string`, [Security Scheme Object](#security-scheme-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Security Scheme Objects](#security-scheme-object). |
| links | Map[`string`, [Link Object](#link-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Link Objects](#link-object). |
| callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Callback Objects](#callback-object). |
| pathItems | Map[`string`, [Path Item Object](#path-item-object)] | An object to hold reusable [Path Item Objects](#path-item-object). |
| mediaTypes | Map[`string`, [Media Type Object](#media-type-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Media Type Objects](#media-type-object). |
This object MAY be extended with [Specification Extensions](#specification-extensions).
All the fixed fields declared above are objects that MUST use keys that match the regular expression: `^[a-zA-Z0-9\.\-_]+$`.
Field Name Examples:
```text
User
User_1
User_Name
user-name
my.org.User
```
#### Components Object Example
```yaml
components:
schemas:
GeneralError:
type: object
properties:
code:
type: integer
format: int32
message:
type: string
Category:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
Tag:
type: object
properties:
id:
type: integer
format: int64
name:
type: string
parameters:
skipParam:
name: skip
in: query
description: number of items to skip
required: true
schema:
type: integer
format: int32
limitParam:
name: limit
in: query
description: max records to return
required: true
schema:
type: integer
format: int32
responses:
NotFound:
description: Entity not found.
IllegalInput:
description: Illegal input for operation.
GeneralError:
description: General Error
content:
application/json:
schema:
$ref: '#/components/schemas/GeneralError'
securitySchemes:
api_key:
type: apiKey
name: api-key
in: header
petstore_auth:
type: oauth2
flows:
implicit:
authorizationUrl: https://example.org/api/oauth/dialog
scopes:
write:pets: modify pets in your account
read:pets: read your pets
```
### Paths Object
Holds the relative paths to the individual endpoints and their operations.
The path is appended to the URL from the [Server Object](#server-object) in order to construct the full URL. The Paths Object MAY be empty, due to [Access Control List (ACL) constraints](#security-filtering).
#### Patterned Fields
| Field Pattern | Type | Description |
| ---- | :----: | ---- |
| /{path} | [Path Item Object](#path-item-object) | A relative path to an individual endpoint. The field name MUST begin with a forward slash (`/`). The URL from the [Server Object](#server-object)'s `url` field, resolved and with template variables substituted, has the path **appended** (no relative URL resolution) to it in order to construct the full URL. [Path templating](#path-templating) is allowed. When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it's up to the tooling to decide which one to use. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Path Templating
Path templating refers to the usage of template expressions, delimited by curly braces (`{}`), to mark a section of a URL path as replaceable using path parameters.
Each template expression in the path MUST correspond to a path parameter that is included in the [Path Item](#path-item-object) itself and/or in each of the Path Item's [Operations](#operation-object). An exception is if the path item is empty, for example due to ACL constraints, matching path parameters are not required.
The value for these path parameters MUST NOT contain any unescaped "generic syntax" characters described by [RFC3986](https://tools.ietf.org/html/rfc3986#section-3): forward slashes (`/`), question marks (`?`), or hashes (`#`).
See [URL Percent-Encoding](#url-percent-encoding) for additional guidance on escaping characters.
The path templating is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax
```abnf
path-template = "/" *( path-segment "/" ) [ path-segment ]
path-segment = 1*( path-literal / template-expression )
path-literal = 1*pchar
template-expression = "{" template-expression-param-name "}"
template-expression-param-name = 1*( %x00-7A / %x7C / %x7E-10FFFF ) ; every Unicode character except { and }
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
```
Here, `pchar`, `unreserved`, `pct-encoded` and `sub-delims` definitions are taken from [RFC 3986](https://tools.ietf.org/html/rfc3986). The `path-template` is directly derived from [RFC 3986, section 3.3](https://datatracker.ietf.org/doc/html/rfc3986#section-3.3).
Each template expression MUST NOT appear more than once in a single path template.
See also [Appendix C: Using RFC6570-Based Serialization](#appendix-c-using-rfc6570-based-serialization) for additional guidance.
##### Path Templating Matching
Assuming the following paths, the concrete definition, `/pets/mine`, will be matched first if used:
```text
/pets/{petId}
/pets/mine
```
The following paths are considered identical and invalid:
```text
/pets/{petId}
/pets/{name}
```
The following may lead to ambiguous resolution:
```text
/{entity}/me
/books/{id}
```
#### Paths Object Example
```yaml
/pets:
get:
description: Returns all pets from the system that the user has access to
responses:
'200':
description: A list of pets.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/pet'
```
### Path Item Object
Describes the operations available on a single path.
A Path Item MAY be empty, due to [ACL constraints](#security-filtering).
The path itself is still exposed to the documentation viewer but they will not know which operations and parameters are available.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| $ref | `string` | Allows for a referenced definition of this path item. The value MUST be in the form of a URI, and the referenced structure MUST be in the form of a [Path Item Object](#path-item-object). In case a Path Item Object field appears both in the defined object and the referenced object, the behavior is undefined. See the rules for resolving [Relative References](#relative-references-in-api-description-uris). type: stringformat: binary | contentMediaType: image/png | if redundant, can be omitted, often resulting in an empty [Schema Object](#schema-object) |
| type: stringformat: byte | type: stringcontentMediaType: image/pngcontentEncoding: base64 | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe |
#### Extended Validation with Annotations
JSON Schema Draft 2020-12 supports [collecting annotations](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-7.7.1), including [treating unrecognized keywords as annotations](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-6.5).
OAS implementations MAY use such annotations, including [extensions](https://spec.openapis.org/registry/extension/) not recognized as part of a declared JSON Schema vocabulary, as the basis for further validation.
Note that JSON Schema Draft 2020-12 does not require an `x-` prefix for extensions.
##### Non-Validating Constraint Keywords
The [`format` keyword (when using default format-annotation vocabulary)](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-7.2.1) and the [`contentMediaType`, `contentEncoding`, and `contentSchema` keywords](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-8.2) define constraints on the data, but are treated as annotations instead of being validated directly.
Extended validation is one way that these constraints MAY be enforced.
##### Validating `readOnly` and `writeOnly`
The `readOnly` and `writeOnly` keywords are annotations, as JSON Schema is not aware of how the data it is validating is being used.
Validation of these keywords MAY be done by checking the annotation, the read or write direction, and (if relevant) the current value of the field.
[JSON Schema Validation Draft 2020-12 Section 9.4](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-9.4) defines the expectations of these keywords, including that a resource (described as the "owning authority") MAY either ignore a `readOnly` field or treat it as an error.
Fields that are both required and read-only are an example of when it is beneficial to ignore a `readOnly: true` constraint in a PUT, particularly if the value has not been changed.
This allows correctly requiring the field on a GET and still using the same representation and schema with PUT.
Even when read-only fields are not required, stripping them is burdensome for clients, particularly when the JSON data is complex or deeply nested.
Note that the behavior of `readOnly` in particular differs from that specified by version 3.0 of this specification.
#### Data Modeling Techniques
##### Composition and Inheritance (Polymorphism)
The OpenAPI Specification allows combining and extending model definitions using the `allOf` keyword 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.
JSON Schema also provides the `anyOf` and `oneOf` keywords, which allow defining multiple schemas where at least one or exactly one of them must be valid, respectively.
As is the case with `allOf`, the schemas are validated _independently_.
These keywords can be used to describe polymorphism, where a single field can accept multiple types of values.
The OpenAPI specification extends the JSON Schema support for polymorphism by adding the [`discriminator`](#schema-discriminator) field whose value is a [Discriminator Object](#discriminator-object).
When used, the Discriminator Object indicates the name of the property that hints which schema of an `anyOf` or `oneOf` is expected to validate the structure of the model.
The discriminating property MAY be defined as required or optional, but when defined as an optional property the Discriminator Object MUST include a `defaultMapping` field that specifies which schema of the `anyOf` or `oneOf`, or which schema that references the current schema in an `allOf`, is expected to validate the structure of the model when the discriminating property is not present.
There are two ways to define the value of a discriminating property for an inheriting instance.
* Use the schema name.
* [Override the schema name](#discriminator-mapping) by overriding the property with a new value. If a new value exists, this takes precedence over the schema name.
##### Generic (Template) Data Structures
Implementations SHOULD support defining generic or template data structures using JSON Schema's dynamic referencing feature:
* `$dynamicAnchor` identifies a set of possible schemas (including a default placeholder schema) to which a `$dynamicRef` can resolve
* `$dynamicRef` resolves to the first matching `$dynamicAnchor` encountered on its path from the schema entry point to the reference, as described in the JSON Schema specification
An example is included in the [Schema Object Examples](#schema-object-examples) section below, and further information can be found on the Learn OpenAPI site's ["Dynamic References"](https://learn.openapis.org/referencing/dynamic.html) page.
##### Annotated Enumerations
The Schema Object's `enum` keyword does not allow associating descriptions or other information with individual values.
Implementations MAY support recognizing a `oneOf` or `anyOf` where each subschema in the keyword's array consists of a `const` keyword and annotations such as `title` or `description` as an enumerated type with additional information. The exact behavior of this pattern beyond what is required by JSON Schema is implementation-defined.
##### XML Modeling
The [xml](#schema-xml) field allows extra definitions when translating the JSON definition to XML.
The [XML Object](#xml-object) contains additional information about the available options.
#### Specifying Schema Dialects
It is important for tooling to be able to determine which dialect or meta-schema any given resource wishes to be processed with: JSON Schema Core, JSON Schema Validation, OpenAPI Schema dialect, or some custom meta-schema.
The `$schema` keyword MAY be present in any Schema Object that is a [schema resource root](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-4.3.5), and if present MUST be used to determine which dialect should be used when processing the schema. This allows use of Schema Objects which comply with other drafts of JSON Schema than the default Draft 2020-12 support. Tooling MUST support the OAS dialect schema id, and MAY support additional values of `$schema`.
To allow use of a different default `$schema` value for all Schema Objects contained within an OAS document, a `jsonSchemaDialect` value may be set within the OpenAPI Object. If this default is not set, then the OAS dialect schema id MUST be used for these Schema Objects. The value of `$schema` within a resource root Schema Object always overrides any default.
For standalone JSON Schema documents that do not set `$schema`, or for Schema Objects in OpenAPI description documents that are _not_ [complete documents](#openapi-description-structure), the dialect SHOULD be assumed to be the OAS dialect.
However, for maximum interoperability, it is RECOMMENDED that OpenAPI description authors explicitly set the dialect through `$schema` in such documents.
#### Schema Object Examples
##### Primitive Example
```yaml
type: string
format: email
```
##### Simple Model
```yaml
type: object
required:
- name
properties:
name:
type: string
address:
$ref: '#/components/schemas/Address'
age:
type: integer
format: int32
minimum: 0
```
##### Model with Map/Dictionary Properties
For a simple string to string mapping:
```yaml
type: object
additionalProperties:
type: string
```
For a string to model mapping:
```yaml
type: object
additionalProperties:
$ref: '#/components/schemas/ComplexModel'
```
##### Model with Annotated Enumeration
```yaml
oneOf:
- const: RGB
title: Red, Green, Blue
description: Specify colors with the red, green, and blue additive color model
- const: CMYK
title: Cyan, Magenta, Yellow, Black
description: Specify colors with the cyan, magenta, yellow, and black subtractive color model
```
##### Model with Example
```yaml
type: object
properties:
id:
type: integer
format: int64
name:
type: string
required:
- name
examples:
- name: Puma
id: 1
```
##### Models with Composition
```yaml
components:
schemas:
ErrorModel:
type: object
required:
- message
- code
properties:
message:
type: string
code:
type: integer
minimum: 100
maximum: 600
ExtendedErrorModel:
allOf:
- $ref: '#/components/schemas/ErrorModel'
- type: object
required:
- rootCause
properties:
rootCause:
type: string
```
##### Models with Polymorphism Support
The following example describes a `Pet` model that can represent either a cat or a dog, as distinguished by the `petType` property. Each type of pet has other properties beyond those of the base `Pet` model. An instance without a `petType` property, or with a `petType` property that does not match either `cat` or `dog`, is invalid.
```yaml
components:
schemas:
Pet:
type: object
properties:
name:
type: string
required:
- name
- petType
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
Cat:
description: A pet cat
type: object
properties:
petType:
const: 'cat'
huntingSkill:
type: string
description: The measured skill for hunting
enum:
- clueless
- lazy
- adventurous
- aggressive
required:
- huntingSkill
Dog:
description: A pet dog
type: object
properties:
petType:
const: 'dog'
packSize:
type: integer
format: int32
description: the size of the pack the dog is from
default: 0
minimum: 0
required:
- packSize
```
##### Models with Polymorphism Support and a Discriminator Object
The following example extends the example of the previous section by adding a [Discriminator Object](#discriminator-object) to the `Pet` schema. Note that the Discriminator Object is only a hint to the consumer of the API and does not change the validation outcome of the schema.
```yaml
components:
schemas:
Pet:
type: object
discriminator:
propertyName: petType
mapping:
cat: '#/components/schemas/Cat'
dog: '#/components/schemas/Dog'
properties:
name:
type: string
required:
- name
- petType
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
Cat:
description: A pet cat
type: object
properties:
petType:
const: 'cat'
huntingSkill:
type: string
description: The measured skill for hunting
enum:
- clueless
- lazy
- adventurous
- aggressive
required:
- huntingSkill
Dog:
description: A pet dog
type: object
properties:
petType:
const: 'dog'
packSize:
type: integer
format: int32
description: the size of the pack the dog is from
default: 0
minimum: 0
required:
- petType
- packSize
```
##### Models with Polymorphism Support using `allOf` and a Discriminator Object
It is also possible to describe polymorphic models using `allOf`. The following example uses `allOf` with a [Discriminator Object](#discriminator-object) to describe a polymorphic `Pet` model.
```yaml
components:
schemas:
Pet:
type: object
discriminator:
propertyName: petType
properties:
name:
type: string
petType:
type: string
required:
- name
- petType
Cat: # "Cat" will be used as the discriminating value
description: A representation of a cat
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
properties:
huntingSkill:
type: string
description: The measured skill for hunting
enum:
- clueless
- lazy
- adventurous
- aggressive
required:
- huntingSkill
Dog: # "Dog" will be used as the discriminating value
description: A representation of a dog
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
properties:
packSize:
type: integer
format: int32
description: the size of the pack the dog is from
default: 0
minimum: 0
required:
- packSize
```
##### Generic Data Structure Model
```yaml
components:
schemas:
genericArrayComponent:
$id: fully_generic_array
type: array
items:
$dynamicRef: '#generic-array'
$defs:
allowAll:
$dynamicAnchor: generic-array
numberArray:
$id: array_of_numbers
$ref: fully_generic_array
$defs:
numbersOnly:
$dynamicAnchor: generic-array
type: number
stringArray:
$id: array_of_strings
$ref: fully_generic_array
$defs:
stringsOnly:
$dynamicAnchor: generic-array
type: string
objWithTypedArray:
$id: obj_with_typed_array
type: object
required:
- dataType
- data
properties:
dataType:
enum:
- string
- number
oneOf:
- properties:
dataType:
const: string
data:
$ref: array_of_strings
- properties:
dataType:
const: number
data:
$ref: array_of_numbers
```
### Discriminator Object
When request bodies or response payloads may be one of a number of different schemas, these should use the JSON Schema `anyOf` or `oneOf` keywords to describe the possible schemas (see [Composition and Inheritance](#composition-and-inheritance-polymorphism)).
A polymorphic schema MAY include a Discriminator Object, which defines the name of the property that may be used as a hint for which schema of the `anyOf` or `oneOf`, or which schema that references the current schema in an `allOf`, is expected to validate the structure of the model.
This hint can be used to aid in serialization, deserialization, and validation.
The Discriminator Object does this by implicitly or explicitly associating the possible values of a named property with alternative schemas.
Note that `discriminator` MUST NOT change the validation outcome of the schema.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| propertyName | `string` | **REQUIRED**. The name of the discriminating property in the payload that will hold the discriminating value. The discriminating property MAY be defined as required or optional, but when defined as optional the Discriminator Object MUST include a `defaultMapping` field that specifies which schema is expected to validate the structure of the model when the discriminating property is not present. |
| mapping | Map[`string`, `string`] | An object to hold mappings between payload values and schema names or URI references. |
| defaultMapping | `string` | The schema name or URI reference to a schema that is expected to validate the structure of the model when the discriminating property is not present in the payload or contains a value for which there is no explicit or implicit mapping. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Conditions for Using the Discriminator Object
The Discriminator Object is legal only when using one of the composite keywords `oneOf`, `anyOf`, `allOf`.
In both the `oneOf` and `anyOf` use cases, where those keywords are adjacent to `discriminator`, all possible schemas MUST be listed explicitly.
To avoid redundancy, the discriminator MAY be added to a parent schema definition, and all schemas building on the parent schema via an `allOf` construct may be used as an alternate schema.
The `allOf` form of `discriminator` is _only_ useful for non-validation use cases; validation with the parent schema with this form of `discriminator` _does not_ perform a search for child schemas or use them in validation in any way.
This is because `discriminator` cannot change the validation outcome, and no standard JSON Schema keyword connects the parent schema to the child schemas.
The behavior of any configuration of `oneOf`, `anyOf`, `allOf` and `discriminator` that is not described above is undefined.
#### Options for Mapping Values to Schemas
The value of the property named in `propertyName` is used as the name of the associated schema under the [Components Object](#components-object), _unless_ a `mapping` is present for that value.
The `mapping` entry maps a specific property value to either a different schema component name, or to a schema identified by a URI.
When using implicit or explicit schema component names, inline `oneOf` or `anyOf` subschemas are not considered.
The behavior of a `mapping` value or `defaultMapping` value that is both a valid schema name and a valid relative URI reference is implementation-defined, but it is RECOMMENDED that it be treated as a schema name.
To ensure that an ambiguous value (e.g. `"foo"`) is treated as a relative URI reference by all implementations, authors MUST prefix it with the `"."` path segment (e.g. `"./foo"`).
Mapping keys MUST be string values, but tooling MAY convert response values to strings for comparison.
However, the exact nature of such conversions are implementation-defined.
#### Optional Discriminating Property
When the discriminating property is defined as optional, the [Discriminator Object](#discriminator-object) MUST include a `defaultMapping` field that specifies a schema that is expected to validate the structure of the model when the discriminating property is not present in the payload or contains a value for which there is no explicit or implicit mapping. This allows the schema to still be validated correctly even if the discriminating property is missing.
The primary use case for an optional discriminating property is to allow a schema to be extended with a discriminator without breaking existing clients that do not provide the discriminating property.
When the discriminating property is defined as optional, it is important that each subschema that defines a value for the discriminating property also define the property as required, since this is no longer enforced by the parent schema.
The `defaultMapping` schema is also expected to validate the structure of the model when the discriminating property is present but contains a value for which there is no explicit or implicit mapping. This is typically expressed in the `defaultMapping` schema by excluding any instances with mapped values of the discriminating property, e.g.
```yaml
OtherPet:
type: object
properties:
petType:
not:
enum: ['cat', 'dog']
```
This prevents the `defaultMapping` schema from validating a payload that includes the discriminating property with a mapped discriminating value, which would cause a validation to fail when polymorphism is described using the `oneOf` JSON schema keyword.
#### Examples
For these examples, assume all schemas are in the [entry document](#openapi-description-structure) of the OAD; for handling of `discriminator` in referenced documents see [Resolving Implicit Connections](#resolving-implicit-connections).
In OAS 3.x, a response payload MAY be described to be exactly one of any number of types:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
```
which means a valid payload has to match exactly one of the schemas described by `Cat`, `Dog`, or `Lizard`. Deserialization of a `oneOf` can be a costly operation, as it requires determining which schema matches the payload and thus should be used in deserialization. This problem also exists for `anyOf` schemas. A `discriminator` can be used as a "hint" to improve the efficiency of selection of the matching schema. The [Discriminator Object](#discriminator-object) cannot change the validation result of the `oneOf`, it can only help make the deserialization more efficient and provide better error messaging. We can specify the exact field that tells us which schema is expected to match the instance:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
discriminator:
propertyName: petType
```
The expectation now is that a property with name `petType` _MUST_ be present in the response payload, and the value will correspond to the name of a schema defined in the OpenAPI Description. Thus the response payload:
```json
{
"id": 12345,
"petType": "Cat"
}
```
will indicate that the `Cat` schema is expected to match this payload.
In scenarios where the value of the discriminating property does not match the schema name or implicit mapping is not possible, an optional `mapping` definition can be used:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
- $ref: https://gigantic-server.com/schemas/Monster/schema.json
discriminator:
propertyName: petType
mapping:
dog: '#/components/schemas/Dog'
monster: https://gigantic-server.com/schemas/Monster/schema.json
```
Here the discriminating value of `dog` will map to the schema `#/components/schemas/Dog`, rather than the default (implicit) value of `#/components/schemas/dog`. If the discriminating value does not match an implicit or explicit mapping, no schema can be determined and validation SHOULD fail.
When used in conjunction with the `anyOf` construct, the use of the discriminator can avoid ambiguity for serializers/deserializers where multiple schemas may satisfy a single payload.
When the discriminating property is defined as optional, the Discriminator Object has to include a `defaultMapping` field that specifies a schema of the `anyOf` or `oneOf` is expected to validate the structure of the model when the discriminating property is not present in the payload. This allows the schema to still be validated correctly even if the discriminator property is missing.
For example:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
- $ref: '#/components/schemas/OtherPet'
discriminator:
propertyName: petType
defaultMapping: OtherPet
OtherPet:
type: object
properties:
petType:
not:
enum: ['Cat', 'Dog', 'Lizard']
```
In this example, if the `petType` property is not present in the payload, or if the value of `petType` is not "Cat", "Dog", or "Lizard", then the payload should validate against the `OtherPet` schema.
This example shows the `allOf` usage, which avoids needing to reference all child schemas in the parent:
```yaml
components:
schemas:
Pet:
type: object
required:
- petType
properties:
petType:
type: string
discriminator:
propertyName: petType
mapping:
dog: Dog
Cat:
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
# all other properties specific to a `Cat`
properties:
name:
type: string
Dog:
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
# all other properties specific to a `Dog`
properties:
bark:
type: string
Lizard:
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
# all other properties specific to a `Lizard`
properties:
lovesRocks:
type: boolean
```
Validated against the `Pet` schema, a payload like this:
```json
{
"petType": "Cat",
"name": "Misty"
}
```
will indicate that the `#/components/schemas/Cat` schema is expected to match. Likewise this payload:
```json
{
"petType": "dog",
"bark": "soft"
}
```
will map to `#/components/schemas/Dog` because the `dog` entry in the `mapping` element maps to `Dog` which is the schema name for `#/components/schemas/Dog`.
### XML Object
A metadata object that allows for more fine-tuned XML model definitions.
When using a Schema Object with XML, if no XML Object is present, the behavior is determined by the XML Object's default field values.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| nodeType | `string` | One of `element`, `attribute`, `text`, `cdata`, or `none`, as explained under [XML Node Types](#xml-node-types). The default value is `none` if `$ref`, `$dynamicRef`, or `type: "array"` is present in the [Schema Object](#schema-object) containing the XML Object, and `element` otherwise. |
| name | `string` | Sets the name of the element/attribute corresponding to the schema, replacing the name that was inferred as described under [XML Node Names](#xml-node-names). This field SHALL be ignored if the `nodeType` is `text`, `cdata`, or `none`. |
| namespace | `string` | The IRI ([[RFC3987]]) of the namespace definition. Value MUST be in the form of a non-relative IRI. |
| prefix | `string` | The prefix to be used for the [name](#xml-name). |
| attribute | `boolean` | Declares whether the property definition translates to an attribute instead of an element. Default value is `false`. If `nodeType` is present, this field MUST NOT be present.Awesome documentation goes here
--boundary-example ``` In this example, the URI for each part, which also serves as its base URI, comes from the part's `Content-Location` header as specified by RFC2557. Since the Schema Object at `#/components/schemas/Foo` does not contain an `$id`, the reference in its subschema uses the OpenAPI document's base URI, which is taken from the `Content-Location` header of its part within the `multipart/related` format. The resulting reference to `https://example.com/schemas/bar` matches the `Content-Location` header of the second part, which according to RFC2557 allows the reference target to be located within the multipart archive. Similarly, the `url` field of the [External Documentation Object](#external-documentation-object) is resolved against the base URI from `Content-Location`, producing `https://example.com/api/docs.html` which matches the `Content-Location` of the third part. ### Base URI From the Retrieval URI If no base URI is provided from either of the previous sources, the next source is the retrieval URI ([RFC3986](https://tools.ietf.org/html/rfc3986#section-5.1.3)). Assume this document was retrieved from `https://example.com/api/openapis.yaml`: ```yaml openapi: 3.2.0 info: title: Example API version: 1.0 components: requestBodies: Foo: content: application/json: schema: $ref: schemas/foo ``` Assume this document was retrieved from `https://example.com/api/schemas/foo`: ```json { "type": "object", "properties": { "bar": { "type": "string" } } } ``` Resolving the `$ref: schemas/foo` against the retrieval URI of the OpenAPI document produces `https://example.com/api/schemas/foo`, the retrieval URI of the JSON Schema document. ### Application-Specific Default Base URI When constructing an OpenAPI document in memory that does not have a `$self`, or an encapsulating entity, or a retrieval URI, applications can resolve internal (fragment-only) references by assuming a default base URI ([RFC3986](https://tools.ietf.org/html/rfc3986#section-5.1.4)). While this sort of internal resolution can be performed in practice without choosing a base URI, choosing one, such as a URN with a randomly generated UUID (e.g. `urn:uuid:f26cdaad-3193-4398-a838-4ecb7326c4c5`) avoids the need to implement it as a special case. ### Resolving Relative `$self` and `$id` Let's re-consider the first example in this appendix, but with relative URI references for `$self` and `$id`, and retrieval URIs that support that relative usage: Assume that the following is retrieved from `https://staging.example.com/api/openapi`: ```yaml openapi: 3.2.0 $self: /api/openapi info: title: Example API version: 1.0 paths: /foo: get: requestBody: $ref: "shared/foo#/components/requestBodies/Foo" ``` Assume the retrieval URI for the following document is `https://staging.example.com/api/shared/foo`: ```yaml openapi: 3.2.0 $self: /api/shared/foo info: title: Shared components for all APIs version: 1.0 components: requestBodies: Foo: content: application/json: schema: $ref: ../schemas/foo schemas: Foo: $id: /api/schemas/foo properties: bar: $ref: bar Bar: $id: /api/schemas/bar type: string ``` In this example, all of the `$self` and `$id` values are relative URI references consisting of an absolute path. This allows the retrieval URI to set the host (and scheme), in this case `https://staging.example.com`, resulting in the first document's `$self` being `https://staging.example.com/openapi`, and the second document's `$self` being `https://staging.example.com/api/shared/foo`, with `$id` values of `https://staging.example.com/api/schemas/foo` and `https://staging.example.com/api/schemas/bar`. Relative `$self` and `$id` values of this sort allow the same set of documents to work when deployed to other hosts, e.g. `https://example.com` (production) or `https://localhost:8080` (local development). ## Appendix G: Parsing and Resolution Guidance Implementations MAY support complete-document parsing in any of the following ways: * Detecting OpenAPI or JSON Schema documents using media types * Detecting OpenAPI documents through the root `openapi` field * Detecting JSON Schema documents through detecting keywords or otherwise successfully parsing the document in accordance with the JSON Schema specification Additional mechanisms can be used to support documents with Objects other than an OpenAPI Object or a Schema Object at the root, but note that the resulting behavior is implementation-defined: * Detecting a document containing a referenceable Object at its root based on the expected type of the reference * Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object ### Warnings Regarding Fragmentary Parsing Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target. In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results. While some implementations support this sort of parsing due to the requirements of past versions of this specification, in version 3.1 and later, the result of parsing fragments in isolation is _undefined_ and likely to contradict the requirements of this specification. While it is possible to structure certain OpenAPI Descriptions to ensure that they will behave correctly when references are parsed as isolated fragments, depending on this is NOT RECOMMENDED. This specification does not explicitly enumerate the conditions under which such behavior is safe and provides no guarantee for continued safety in any future versions of the OAS. ### Conflicts Between Field Types and Reference Contexts JSON or YAML objects within an OAD are interpreted as specific Objects (such as [Operation Objects](#operation-object), [Response Objects](#response-object), [Reference Objects](#reference-object), etc.) based on their context. Depending on how references are arranged, a given JSON or YAML object can be interpreted in multiple different contexts: * As the root object of the [entry document](#openapi-description-structure), which is always interpreted as an OpenAPI Object * As the Object type implied by its parent Object's field within the document * As a reference target, with the Object type matching the reference source's context If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as _different_ Object types, the resulting behavior is _implementation defined_, and MAY be treated as an error if detected. An example would be referencing an empty Schema Object under `#/components/schemas` where a Path Item Object is expected, as an empty object is valid for both types. For maximum interoperability, it is RECOMMENDED that OpenAPI Description authors avoid such scenarios. ### Guidance Regarding Implicit Connections The following Objects and Fields involve the use of implicit connections: | Source | Target | Alternative | | ---- | ---- | ---- | | [Security Requirement Object](#security-requirement-object) `{name}` | [Security Scheme Object](#security-scheme-object) name under the [Components Object](#components-object) | _n/a_ | | [Discriminator Object](#discriminator-object) `mapping` _(implicit, or explicit name syntax)_ | [Schema Object](#schema-object) name under the Components Object | `mapping` _(explicit URI syntax)_ | | [Operation Object](#operation-object) `tags` | [Tag Object](#tag-object) `name` (in the [OpenAPI Object](#openapi-object)'s `tags` array) | _n/a_ | | [Link Object](#link-object) `operationId` | [Operation Object](#operation-object) `operationId` | `operationRef` | An additional implicit connection involves appending the templated URL paths of the [Paths Object](#paths-object) to the appropriate [Server Object](#server-object)'s `url` field. This connection is unambiguous because only the entry document's Paths Object contributes URLs to the described API. The implicit connections in the Security Requirement Object and Discriminator Object rely on the _component name_, which is the name of the property holding the component in the appropriately typed sub-object of the Components Object. For example, the component name of the Schema Object at `#/components/schemas/Foo` is `Foo`. The implicit connection of `tags` in the Operation Object uses the `name` field of Tag Objects, which (like the Components Object) are found under the root OpenAPI Object. This means resolving component names and tag names both depend on starting from the correct OpenAPI Object. For resolving component and tag name connections from a referenced (non-entry) document, it is RECOMMENDED that tools resolve from the entry document, rather than the current document. Resolving component and tag name connections from a referenced (non-entry) document to the entry document as recommended under [Resolving Implicit Connections](#resolving-implicit-connections) allows components and Tag Objects to be defined next to the API's deployment information in the top-level array of Server Objects and treated as an interface for referenced documents to access. For Security Requirement Objects and Discriminator Objects, it is also possible to keep the resolution within the referenced document by using the URI-reference form that these Objects offer. There are no URI-based alternatives for the Operation Object's `tags` field. OAD authors are advised to use external solutions such as the OpenAPI Initiative's Overlay Specification to simulate sharing [Tag Objects](#tag-object) across multiple documents. #### Implicit Connection Resolution Examples This section shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. The behavior for Discriminator Object non-URI mappings and for the Operation Object's `tags` field operate on the same principles. First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document: ```http GET /api/description/openapi HTTP/1.1 Host: www.example.com Accept: application/openapi+json ``` ```json "components": { "securitySchemes": { "MySecurity": { "type": "http", "scheme": "bearer", "bearerFormat": "JWT" } } }, "paths": { "/foo": { "$ref": "other#/components/pathItems/Foo" } } ``` ```http GET /api/description/openapi HTTP/1.1 Host: www.example.com Accept: application/openapi+yaml ``` ```yaml components: securitySchemes: MySecurity: type: http scheme: bearer bearerFormat: JWT paths: /foo: $ref: 'other#/components/pathItems/Foo' ``` This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available: ```http GET /api/description/other HTTP/1.1 Host: www.example.com Accept: application/openapi+json ``` ```json "components": { "securitySchemes": { "MySecurity": { "type": "http", "scheme": "basic" } }, "pathItems": { "Foo": { "get": { "security": [ "MySecurity": [] ] } } } } ``` ```http GET /api/description/other HTTP/1.1 Host: www.example.com Accept: application/openapi+yaml ``` ```yaml components: securitySchemes: MySecurity: type: http scheme: basic pathItems: Foo: get: security: - MySecurity: [] ``` In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior), but the section formally recommends that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported. OpenAPI-Specification-3.2.1/versions/3.2.1-editors.md 0000664 0000000 0000000 00000001640 15250560344 0022035 0 ustar 00root root 0000000 0000000 # OpenAPI Specification Editors ## Active * Henry Andrews [@handrews](https://github.com/handrews) * Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc) * Karen Etheridge [@karenetheridge](https://github.com/karenetheridge) * Lorna Mitchell [@lornajane](https://github.com/lornajane) * Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh) * Miguel Quintero [@miqui](https://github.com/miqui) * Mike Kistler [@mikekistler](https://github.com/mikekistler) * Ralf Handl [@ralfhandl](https://github.com/ralfhandl) * Vincent Biret [@baywet](https://github.com/baywet) ## Emeritus * Ron Ratovsky [@webron](https://github.com/webron) * Darrel Miller [@darrelmiller](https://github.com/darrelmiller) * Mike Ralphson [@MikeRalphson](https://github.com/MikeRalphson) * Uri Sarid [@usarid](https://github.com/usarid) * Jason Harmon [@jharmn](https://github.com/jharmn) * Tony Tam [@fehguy](https://github.com/fehguy) OpenAPI-Specification-3.2.1/versions/3.2.1.md 0000664 0000000 0000000 00001106224 15250560344 0020373 0 ustar 00root root 0000000 0000000 # OpenAPI Specification ## Version 3.2.1 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](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here. This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html). ## Introduction The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service by [parsing and serializing](#parsing-and-serializing) HTTP messages to and from a [data model](#data-types) with a minimal amount of implementation logic. An [OpenAPI Description](#openapi-description-structure) (OAD) can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases. For examples of OpenAPI usage and additional documentation, please visit [[?OpenAPI-Learn]]. For extension registries and other specifications published by the OpenAPI Initiative, as well as the authoritative rendering of this specification, please visit [spec.openapis.org](https://spec.openapis.org/). ### Versions and Deprecation The OpenAPI Specification is versioned using a `major`.`minor`.`patch` versioning scheme. The `major`.`minor` portion of the version string (for example `3.1`) SHALL designate the OAS feature set. _`.patch`_ versions address errors in, or provide clarifications to, this document, not the feature set. Tooling which supports OAS 3.1 SHOULD be compatible with all OAS 3.1.\* versions. The patch version SHOULD NOT be considered by tooling, making no distinction between `3.1.0` and `3.1.1` for example. Certain fields or features may be marked **Deprecated**. These fields and features remain part of the specification and can be used like any other field or feature. However, OpenAPI Description authors should use newer fields and features documented to replace the deprecated ones whenever possible. At this time, such elements are expected to remain part of the OAS until the next major version, although a future minor version of this specification may define a policy for later removal of deprecated elements. Occasionally, non-backwards compatible changes may be made in `minor` versions of the OAS where impact is believed to be low relative to the benefit provided. ### Undefined and Implementation-Defined Behavior This specification deems certain situations to have either _undefined_ or _implementation-defined_ behavior. Behavior described as _undefined_ is likely, at least in some circumstances, to result in outcomes that contradict the specification. This description is used when detecting the contradiction is impossible or impractical. Implementations MAY support undefined scenarios for historical reasons, including ambiguous text in prior versions of the specification. This support might produce correct outcomes in many cases, but relying on it is NOT RECOMMENDED as there is no guarantee that it will work across all tools or with future specification versions, even if those versions are otherwise strictly compatible with this one. Behavior described as _implementation-defined_ allows implementations to choose which of several different-but-compliant approaches to a requirement to implement. This documents ambiguous requirements that API description authors are RECOMMENDED to avoid in order to maximize interoperability. Unlike undefined behavior, it is safe to rely on implementation-defined behavior if _and only if_ it can be guaranteed that all relevant tools support the same behavior. ## Format An OpenAPI document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in [[RFC8259|JSON]] or [[YAML|YAML]] format. Examples in this specification will be shown in YAML for brevity. All field names in the specification are **case-sensitive**. This includes all fields that are used as keys in a map, except where explicitly noted that keys are **case-insensitive**. OAS [Objects](#objects-and-fields) expose two types of fields: _fixed fields_, which have a declared name, and _patterned fields_, which have a declared pattern for the field name. Patterned fields MUST have unique names within the containing object. **Note:** While APIs may be described by OpenAPI Descriptions in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML. ### JSON and YAML Compatibility In order to preserve the ability to round-trip between YAML and JSON formats, YAML version [1.2](https://yaml.org/spec/1.2/spec.html) is RECOMMENDED along with the additional constraints listed in [[!RFC9512]] [Section 3.4](https://www.rfc-editor.org/rfc/rfc9512.html#name-yaml-and-json). The recommendation in previous versions of this specification to restrict YAML to its "JSON" [schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231) allowed for the inclusion of certain values that (despite the name) cannot be represented in JSON. OAD authors SHOULD NOT rely on any such JSON-incompatible YAML values. ### Case Sensitivity As most field names and values in the OpenAPI Specification are case-sensitive, this document endeavors to call out any case-insensitive names and values. However, the case sensitivity of field names and values that map directly to HTTP concepts follow the case sensitivity rules of HTTP, even if this document does not make a note of every concept. ### Rich Text Formatting Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting. Where OpenAPI tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [CommonMark 0.27](https://spec.commonmark.org/0.27/). Tooling MAY choose to ignore some CommonMark or extension features to address security concerns. While the framing of CommonMark 0.27 as a minimum requirement means that tooling MAY choose to implement extensions on top of it, note that any such extensions are by definition implementation-defined and will not be interoperable. OpenAPI Description authors SHOULD consider how text using such extensions will be rendered by tools that offer only the minimum support. ## Objects and Fields This section describes the structure of the OpenAPI Description format. This text is the only normative description of the format. A JSON Schema is hosted on [spec.openapis.org](https://spec.openapis.org) for informational purposes. If the JSON Schema differs from this section, then this section MUST be considered authoritative. In the following description, if a field is not explicitly **REQUIRED** or described with a MUST or SHALL, it can be considered OPTIONAL. ### OpenAPI Object This is the root object of the [OpenAPI Description](#openapi-description-structure). #### Fixed Fields In addition to the required fields, at least one of the `components`, `paths`, or `webhooks` fields MUST be present. | Field Name | Type | Description | | ---- | :----: | ---- | | openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions-and-deprecation) of the OpenAPI Specification that the OpenAPI document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI document. This is _not_ related to the [`info.version`](#info-version) string, which describes the OpenAPI document's version. | | $self | `string` | This string MUST be in the form of a URI reference as defined by [[RFC3986]] [Section 4.1](https://www.rfc-editor.org/rfc/rfc3986#section-4.1). The `$self` field provides the self-assigned URI of this document, which also serves as its base URI in accordance with [[RFC3986]] [Section 5.1.1](https://www.rfc-editor.org/rfc/rfc3986#section-5.1.1). Implementations MUST support identifying the targets of [API description URIs](#relative-references-in-api-description-uris) using the URI defined by this field when it is present. See [Establishing the Base URI](#establishing-the-base-uri) for the base URI behavior when `$self` is absent or relative, and see [Appendix F](#appendix-f-examples-of-base-uri-determination-and-reference-resolution) for examples of using `$self` to resolve references. | | info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required. | | jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI. See [JSON Schema Keywords](#json-schema-keywords) to determine the default value. | | servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` field is not provided, or is an empty array, the default value would be an array consisting of a single [Server Object](#server-object) with a [url](#server-url) value of `/`. | | paths | [Paths Object](#paths-object) | The available paths and operations for the API. | | webhooks | Map[`string`, [Path Item Object](#path-item-object)] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](https://learn.openapis.org/examples/v3.1/webhook-example.html) is available. | | components | [Components Object](#components-object) | An element to hold various Objects for the OpenAPI Description. | | security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. The list can be incomplete, up to being empty or absent. To make security explicitly optional, an empty security requirement (`{}`) can be included in the array. | | tags | [[Tag Object](#tag-object)] | A list of tags used by the OpenAPI Description with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique. | | externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation. | This object MAY be extended with [Specification Extensions](#specification-extensions). To ensure interoperability, references MUST use the target document's `$self` URI if the `$self` field is present. Implementations MAY choose to support referencing by other URIs such as the retrieval URI even when `$self` is present, however this behavior is not interoperable and relying on it is NOT RECOMMENDED. #### OpenAPI Description Structure An **OpenAPI Description** (**OAD**) formally describes the surface of an API and its semantics. An OAD MAY be made up of a single document, or be distributed across multiple documents that are connected by various fields using [URI references](#relative-references-in-api-description-uris) and [implicit connections](#resolving-implicit-connections). In order for parsing behavior to be well-defined, all documents in an OAD MUST have either an OpenAPI Object or a Schema Object at the root, and MUST be parsed as complete documents, as described in the next section. Documents with a different Object at the root, or that mix OAD content with other content, MAY be supported, but will have implementation-defined or, potentially, undefined behavior as described in [Appendix G: Parsing and Resolution Guidance](#appendix-g-parsing-and-resolution-guidance). Throughout this specification, documents are assumed to have either an OpenAPI Object or Schema Object at the root unless otherwise specified. In a multi-document OAD, the document containing the OpenAPI Object where parsing begins is known as that OAD's **entry document**. It is RECOMMENDED that the entry document of an OAD be named `openapi.json` or `openapi.yaml`. An OpenAPI Object MAY be embedded in another format, called the **embedding format**, just as JSON Schema is embedded in the OAS in the form of Schema Objects. It is the responsibility of an embedding format to define how to parse embedded content, and OAS implementations that do not document support for an embedding format cannot be expected to parse embedded OAS content correctly. ##### Parsing Documents Each document in an OAD MUST be fully parsed in order to locate possible reference targets. This includes the parsing requirements of [JSON Schema Specification Draft 2020-12](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-9), with appropriate modifications regarding base URIs as specified in [Relative References In URIs](#relative-references-in-api-description-uris). Reference targets are defined by fields including the OpenAPI Object's [`$self`](#oas-self) field and the [Schema Object's](#schema-object) `$id`, `$anchor`, and `$dynamicAnchor` keywords. Implementations MUST NOT treat a reference as unresolvable before completely parsing all documents provided to the implementation as possible parts of the OAD. If only the referenced part of the document is parsed when resolving a reference, the resulting behavior can be implementation-defined or undefined; see [Warnings Regarding Fragmentary Parsing](#warnings-regarding-fragmentary-parsing) in [Appendix G](#appendix-g-parsing-and-resolution-guidance) for details. ##### Relative References in API Description URIs URIs used as references within an OpenAPI Description, or to external documentation or other supplementary information such as a license, are resolved as _identifiers_, and described by this specification as **_URIs_**, in contrast with [API URLs](#relative-references-in-api-urls). Note that some URI fields are named `url` for historical reasons, but the descriptive text for those fields uses the correct "URI" terminology. As noted under [Parsing Documents](#parsing-documents), several fields can be used to associate an OpenAPI document or a Schema Object with a URI, which might not match the document's or schema's location. This allows the same references to be used in different deployment environments, including local filesystems or networks restricted by security policies or connectivity limitations. Unless specified otherwise, all fields that are URIs MAY be relative references as defined by [[RFC3986]] [Section 4.2](https://tools.ietf.org/html/rfc3986#section-4.2). ###### Establishing the Base URI Relative URI references are resolved using the appropriate base URI, which MUST be determined in accordance with [[RFC3986]] [Section 5.1.1 – 5.1.4](https://tools.ietf.org/html/rfc3986#section-5.1.1) and, for Schema objects, [JSON Schema draft 2020-12 Section 8.2](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-8.2), as illustrated by the examples in [Appendix F: Examples of Base URI Determination and Reference Resolution](#appendix-f-examples-of-base-uri-determination-and-reference-resolution). If `$self` is a relative URI reference, it is resolved against the next possible base URI source ([[RFC3986]] [Section 5.1.2 – 5.1.4](https://tools.ietf.org/html/rfc3986#section-5.1.2)) before being used for the resolution of other relative URI references. The most common base URI source that is used in the event of a missing or relative `$self` (in the [OpenAPI Object](#openapi-object)) and (for [Schema Object](#schema-object)) `$id` is the retrieval URI. Implementations MAY support document retrieval, although see the [Security Considerations](#security-considerations) sections for additional guidance. Even if retrieval is supported, it may be impossible due to network configuration or server unavailability (including the server hosting an older version while a new version is in development), or undesirable due to performance impacts. Therefore, all implementations SHOULD allow users to provide documents with their intended retrieval URIs so that references can be resolved as if retrievals were performed. ###### Resolving URI fragments If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document. If the representation of the referenced document is JSON or YAML, then the fragment identifier SHOULD be interpreted as a JSON Pointer as per [RFC6901](https://tools.ietf.org/html/rfc6901). ###### Relative URI References in CommonMark Fields Relative references in CommonMark hyperlinks are resolved in their rendered context, which might differ from the context of the API description. ##### Resolving Implicit Connections Several features of this specification require resolution of non-URI-based connections to some other part of the OpenAPI Description (OAD). These connections are unambiguously resolved in single-document OADs, but the resolution process in multi-document OADs is _implementation-defined_, within the constraints described in this section. In some cases, an unambiguous URI-based alternative is available, and OAD authors are RECOMMENDED to use the alternative to maximize interoperability. For resolving [Components Object](#components-object) and [Tag Object](#tag-object) names from a referenced (non-entry) document, it is RECOMMENDED that tools resolve from the entry document, rather than the current document. For resolving an [Operation Object](#operation-object) based on an `operationId`, it is RECOMMENDED to consider all Operation Objects from all parsed documents. Note that no aspect of implicit connection resolution changes how [URIs are resolved](#relative-references-in-api-description-uris), or restricts their possible targets. See [Appendix G: Parsing and Resolution Guidance](#appendix-g-parsing-and-resolution-guidance) for more details, including a list of Objects and fields using implicit connections. ### Info Object The object provides metadata about the API. The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience. #### Fixed Fields | Field Name | Type | Description | | ---- | :----: | ---- | | title | `string` | **REQUIRED**. The title of the API. | | summary | `string` | A short summary of the API. | | description | `string` | A description of the API. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. | | termsOfService | `string` | A URI for the Terms of Service for the API. This MUST be in the form of a URI. | | contact | [Contact Object](#contact-object) | The contact information for the exposed API. | | license | [License Object](#license-object) | The license information for the exposed API. | | version | `string` | **REQUIRED**. The version of the OpenAPI document (which is distinct from the [OpenAPI Specification version](#oas-version) or the version of the API being described or the version of the OpenAPI Description). | This object MAY be extended with [Specification Extensions](#specification-extensions). #### Info Object Example ```yaml title: Example Pet Store App summary: A pet store manager. description: This is an example server for a pet store. termsOfService: https://example.com/terms/ contact: name: API Support url: https://www.example.com/support email: support@example.com license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html version: 1.0.1 ``` ### Contact Object Contact information for the exposed API. #### Fixed Fields | Field Name | Type | Description | | ---- | :----: | ---- | | name | `string` | The identifying name of the contact person/organization. | | url | `string` | The URI for the contact information. This MUST be in the form of a URI. | | email | `string` | The email address of the contact person/organization. This MUST be in the form of an email address. | This object MAY be extended with [Specification Extensions](#specification-extensions). #### Contact Object Example ```yaml name: API Support url: https://www.example.com/support email: support@example.com ``` ### License Object License information for the exposed API. #### Fixed Fields | Field Name | Type | Description | | ---- | :----: | ---- | | name | `string` | **REQUIRED**. The license name used for the API. | | identifier | `string` | An [SPDX](https://spdx.org/licenses/) license expression for the API. The `identifier` field is mutually exclusive of the `url` field. | | url | `string` | A URI for the license used for the API. This MUST be in the form of a URI. The `url` field is mutually exclusive of the `identifier` field. | This object MAY be extended with [Specification Extensions](#specification-extensions). #### License Object Example ```yaml name: Apache 2.0 identifier: Apache-2.0 ``` ### Server Object An object representing a Server. #### Fixed Fields | Field Name | Type | Description | | ---- | :----: | ---- | | url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the document containing the Server Object is being served. Query and fragment MUST NOT be part of this URL. Variable substitutions will be made when a variable is named in `{`braces`}`. | | description | `string` | An optional string describing the host designated by the URL. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. | | name | `string` | An optional unique string to refer to the host designated by the URL. | | variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is used for substitution in the server's URL template. | This object MAY be extended with [Specification Extensions](#specification-extensions). #### Relative References in API URLs API endpoints are by definition accessed as locations, and are described by this specification as **_URLs_**. Unless specified otherwise, all fields that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2). Because the API is a distinct entity from the OpenAPI document, RFC3986's base URI rules for the OpenAPI document do not apply. Unless specified otherwise, relative references are resolved using the URLs defined in the [Server Object](#server-object) as a base URL. Note that these themselves MAY be relative to the referring document. ##### Examples of API Base URL Determination Assume a retrieval URI of `https://device1.example.com` for the following OpenAPI document: ```yaml openapi: 3.2.1 $self: https://apidescriptions.example.com/foo info: title: Example API version: 1.0 servers: - url: . description: The production API on this device - url: ./test description: The test API on this device ``` For API URLs the `$self` field, which identifies the OpenAPI document, is ignored and the retrieval URI is used instead. This produces a normalized production URL of `https://device1.example.com`, and a normalized test URL of `https://device1.example.com/test`. #### Server Object Example A single server would be described as: ```yaml url: https://development.gigantic-server.com/v1 description: Development server name: dev ``` The following shows how multiple servers can be described, for example, at the OpenAPI Object's [`servers`](#oas-servers): ```yaml servers: - url: https://development.gigantic-server.com/v1 description: Development server name: dev - url: https://staging.gigantic-server.com/v1 description: Staging server name: staging - url: https://api.gigantic-server.com/v1 description: Production server name: prod ``` The following shows how variables can be used for a server configuration: ```yaml servers: - url: https://{username}.gigantic-server.com:{port}/{basePath} description: The production API server name: prod variables: username: # note! no enum here means it is an open value default: demo description: A user-specific subdomain. Use `demo` for a free sandbox environment. port: enum: - '8443' - '443' default: '8443' basePath: # open meaning there is the opportunity to use special base paths as assigned by the provider, default is "v2" default: v2 ``` ### Server Variable Object An object representing a Server Variable for server URL template substitution. The server URL templating is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax: ```abnf server-url-template = 1*( literals / server-variable ) server-variable = "{" server-variable-name "}" server-variable-name = 1*( %x00-7A / %x7C / %x7E-10FFFF ) ; every Unicode character except { and } literals = 1*( %x21 / %x23-24 / %x26-3B / %x3D / %x3F-5B / %x5D / %x5F / %x61-7A / %x7E / ucschar / iprivate / pct-encoded) ; any Unicode character except: CTL, SP, ; DQUOTE, "%" (aside from pct-encoded), ; "<", ">", "\", "^", "`", "{", "|", "}" pct-encoded = "%" HEXDIG HEXDIG ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD / %xD0000-DFFFD / %xE1000-EFFFD iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD ``` Here, `literals`, `pct-encoded`, `ucschar` and `iprivate` definitions are taken from [RFC 6570](https://www.rfc-editor.org/rfc/rfc6570), incorporating the corrections specified in [Errata 6937](https://www.rfc-editor.org/errata/eid6937) for `literals`. Each server variable MUST NOT appear more than once in the URL template. See the [Paths Object](#paths-object) for guidance on constructing full request URLs. #### Fixed Fields | Field Name | Type | Description | | ---- | :----: | ---- | | enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array MUST NOT be empty. | | default | `string` | **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. If the [`enum`](#server-variable-enum) is defined, the value MUST exist in the enum's values. Note that this behavior is different from the [Schema Object](#schema-object)'s `default` keyword, which documents the receiver's behavior rather than inserting the value into the data. | | description | `string` | An optional description for the server variable. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. | This object MAY be extended with [Specification Extensions](#specification-extensions). ### Components Object Holds a set of reusable objects for different aspects of the OAS. All objects defined within the Components Object will have no effect on the API unless they are explicitly referenced from outside the Components Object. #### Fixed Fields | Field Name | Type | Description | | ---- | :---- | ---- | | schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object). | | responses | Map[`string`, [Response Object](#response-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Response Objects](#response-object). | | parameters | Map[`string`, [Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Parameter Objects](#parameter-object). | | examples | Map[`string`, [Example Object](#example-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Example Objects](#example-object). | | requestBodies | Map[`string`, [Request Body Object](#request-body-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Request Body Objects](#request-body-object). | | headers | Map[`string`, [Header Object](#header-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Header Objects](#header-object). | | securitySchemes | Map[`string`, [Security Scheme Object](#security-scheme-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Security Scheme Objects](#security-scheme-object). | | links | Map[`string`, [Link Object](#link-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Link Objects](#link-object). | | callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Callback Objects](#callback-object). | | pathItems | Map[`string`, [Path Item Object](#path-item-object)] | An object to hold reusable [Path Item Objects](#path-item-object). | | mediaTypes | Map[`string`, [Media Type Object](#media-type-object) \| [Reference Object](#reference-object)] | An object to hold reusable [Media Type Objects](#media-type-object). | This object MAY be extended with [Specification Extensions](#specification-extensions). All the fixed fields declared above are objects that MUST use keys that match the regular expression: `^[a-zA-Z0-9\.\-_]+$`. Field Name Examples: ```text User User_1 User_Name user-name my.org.User ``` #### Components Object Example ```yaml components: schemas: GeneralError: type: object properties: code: type: integer format: int32 message: type: string Category: type: object properties: id: type: integer format: int64 name: type: string Tag: type: object properties: id: type: integer format: int64 name: type: string parameters: skipParam: name: skip in: query description: number of items to skip required: true schema: type: integer format: int32 limitParam: name: limit in: query description: max records to return required: true schema: type: integer format: int32 responses: NotFound: description: Entity not found. IllegalInput: description: Illegal input for operation. GeneralError: description: General Error content: application/json: schema: $ref: '#/components/schemas/GeneralError' securitySchemes: api_key: type: apiKey name: api-key in: header petstore_auth: type: oauth2 flows: implicit: authorizationUrl: https://example.org/api/oauth/dialog scopes: write:pets: modify pets in your account read:pets: read your pets ``` ### Paths Object Holds the relative paths to the individual endpoints and their operations. The path is appended to the URL from the [Server Object](#server-object) in order to construct the full URL. The Paths Object MAY be empty, due to [Access Control List (ACL) constraints](#security-filtering). #### Patterned Fields | Field Pattern | Type | Description | | ---- | :----: | ---- | | /{path} | [Path Item Object](#path-item-object) | A relative path to an individual endpoint. The field name MUST begin with a forward slash (`/`). The URL from the [Server Object](#server-object)'s `url` field, resolved and with template variables substituted, has the path **appended** (no relative URL resolution) to it in order to construct the full URL. [Path templating](#path-templating) is allowed. When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it's up to the tooling to decide which one to use. | This object MAY be extended with [Specification Extensions](#specification-extensions). #### Path Templating Path templating refers to the usage of template expressions, delimited by curly braces (`{}`), to mark a section of a URL path as replaceable using path parameters. Each template expression in the path MUST correspond to a path parameter that is included in the [Path Item](#path-item-object) itself and/or in each of the Path Item's [Operations](#operation-object). An exception is if the path item is empty, for example due to ACL constraints, matching path parameters are not required. The value for these path parameters MUST NOT contain any unescaped "generic syntax" characters described by [RFC3986](https://tools.ietf.org/html/rfc3986#section-3): forward slashes (`/`), question marks (`?`), or hashes (`#`). This means that when matching templates to request URLs, no values that include a forward slash are matched. For example, the template `/foo/{bar}` cannot match the URI path "/foo/alpha/beta" because the value of the template variable "bar" would have to be "alpha/beta". See [URL Percent-Encoding](#url-percent-encoding) for additional guidance on escaping characters. The path templating is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax: ```abnf path-template = "/" *( path-segment "/" ) [ path-segment ] path-segment = 1*( path-literal / template-expression ) path-literal = 1*pchar template-expression = "{" template-expression-param-name "}" template-expression-param-name = 1*( %x00-7A / %x7C / %x7E-10FFFF ) ; every Unicode character except { and } pchar = unreserved / pct-encoded / sub-delims / ":" / "@" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" pct-encoded = "%" HEXDIG HEXDIG sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ``` Here, `pchar`, `unreserved`, `pct-encoded` and `sub-delims` definitions are taken from [RFC 3986](https://tools.ietf.org/html/rfc3986). The `path-template` is directly derived from [RFC 3986, section 3.3](https://datatracker.ietf.org/doc/html/rfc3986#section-3.3). Each template expression MUST NOT appear more than once in a single path template. See also [Appendix C: Using RFC6570-Based Serialization](#appendix-c-using-rfc6570-based-serialization) for additional guidance. ##### Path Templating Matching Assuming the following paths, the concrete definition, `/pets/mine`, will be matched first if used: ```text /pets/{petId} /pets/mine ``` The following paths are considered identical and invalid: ```text /pets/{petId} /pets/{name} ``` The following may lead to ambiguous resolution: ```text /{entity}/me /books/{id} ``` #### Paths Object Example ```yaml /pets: get: description: Returns all pets from the system that the user has access to responses: '200': description: A list of pets. content: application/json: schema: type: array items: $ref: '#/components/schemas/pet' ``` ### Path Item Object Describes the operations available on a single path. A Path Item MAY be empty, due to [ACL constraints](#security-filtering). The path itself is still exposed to the documentation viewer but they will not know which operations and parameters are available. #### Fixed Fields | Field Name | Type | Description | | ---- | :----: | ---- | | $ref | `string` | Allows for a referenced definition of this path item. The value MUST be in the form of a URI, and the referenced structure MUST be in the form of a [Path Item Object](#path-item-object). In case a Path Item Object field appears both in the defined object and the referenced object, the behavior is undefined. See the rules for resolving [Relative References](#relative-references-in-api-description-uris).type: stringformat: binary | contentMediaType: image/png | if redundant, can be omitted, often resulting in an empty [Schema Object](#schema-object) |
| type: stringformat: byte | type: stringcontentMediaType: image/pngcontentEncoding: base64 | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe |
#### Extended Validation with Annotations
JSON Schema Draft 2020-12 supports [collecting annotations](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-7.7.1), including [treating unrecognized keywords as annotations](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-6.5).
OAS implementations MAY use such annotations, including [extensions](https://spec.openapis.org/registry/extension/) not recognized as part of a declared JSON Schema vocabulary, as the basis for further validation.
Note that JSON Schema Draft 2020-12 does not require an `x-` prefix for extensions.
##### Non-Validating Constraint Keywords
The [`format` keyword (when using default format-annotation vocabulary)](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-7.2.1) and the [`contentMediaType`, `contentEncoding`, and `contentSchema` keywords](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-8.2) define constraints on the data, but are treated as annotations instead of being validated directly.
Extended validation is one way that these constraints MAY be enforced.
##### Validating `readOnly` and `writeOnly`
The `readOnly` and `writeOnly` keywords are annotations, as JSON Schema is not aware of how the data it is validating is being used.
Validation of these keywords MAY be done by checking the annotation, the read or write direction, and (if relevant) the current value of the field.
[JSON Schema Validation Draft 2020-12 Section 9.4](https://www.ietf.org/archive/id/draft-bhutton-json-schema-validation-01.html#section-9.4) defines the expectations of these keywords, including that a resource (described as the "owning authority") MAY either ignore a `readOnly` field or treat it as an error.
Fields that are both required and read-only are an example of when it is beneficial to ignore a `readOnly: true` constraint in a PUT, particularly if the value has not been changed.
This allows correctly requiring the field on a GET and still using the same representation and schema with PUT.
Even when read-only fields are not required, stripping them is burdensome for clients, particularly when the JSON data is complex or deeply nested.
Note that the behavior of `readOnly` in particular differs from that specified by version 3.0 of this specification.
#### Data Modeling Techniques
##### Composition and Inheritance (Polymorphism)
The OpenAPI Specification allows combining and extending model definitions using the `allOf` keyword 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.
JSON Schema also provides the `anyOf` and `oneOf` keywords, which allow defining multiple schemas where at least one or exactly one of them must be valid, respectively.
As is the case with `allOf`, the schemas are validated _independently_.
These keywords can be used to describe polymorphism, where a single field can accept multiple types of values.
The OpenAPI specification extends the JSON Schema support for polymorphism by adding the [`discriminator`](#schema-discriminator) field whose value is a [Discriminator Object](#discriminator-object).
When used, the Discriminator Object indicates the name of the property that hints which schema of an `anyOf` or `oneOf` is expected to validate the structure of the model.
The discriminating property MAY be defined as required or optional, but when defined as an optional property the Discriminator Object MUST include a `defaultMapping` field that specifies which schema of the `anyOf` or `oneOf`, or which schema that references the current schema in an `allOf`, is expected to validate the structure of the model when the discriminating property is not present.
There are two ways to define the value of a discriminating property for an inheriting instance.
* Use the schema name.
* [Override the schema name](#discriminator-mapping) by overriding the property with a new value. If a new value exists, this takes precedence over the schema name.
##### Generic (Template) Data Structures
Implementations SHOULD support defining generic or template data structures using JSON Schema's dynamic referencing feature:
* `$dynamicAnchor` identifies a set of possible schemas (including a default placeholder schema) to which a `$dynamicRef` can resolve
* `$dynamicRef` resolves to the first matching `$dynamicAnchor` encountered on its path from the schema entry point to the reference, as described in the JSON Schema specification
An example is included in the [Schema Object Examples](#schema-object-examples) section below, and further information can be found on the Learn OpenAPI site's ["Dynamic References"](https://learn.openapis.org/referencing/dynamic.html) page.
##### Annotated Enumerations
The Schema Object's `enum` keyword does not allow associating descriptions or other information with individual values.
Implementations MAY support recognizing a `oneOf` or `anyOf` where each subschema in the keyword's array consists of a `const` keyword and annotations such as `title` or `description` as an enumerated type with additional information. The exact behavior of this pattern beyond what is required by JSON Schema is implementation-defined.
##### XML Modeling
The [xml](#schema-xml) field allows extra definitions when translating the JSON definition to XML.
The [XML Object](#xml-object) contains additional information about the available options.
#### Specifying Schema Dialects
It is important for tooling to be able to determine which dialect or meta-schema any given resource wishes to be processed with: JSON Schema Core, JSON Schema Validation, OpenAPI Schema dialect, or some custom meta-schema.
The `$schema` keyword MAY be present in any Schema Object that is a [schema resource root](https://www.ietf.org/archive/id/draft-bhutton-json-schema-01.html#section-4.3.5), and if present MUST be used to determine which dialect should be used when processing the schema. This allows use of Schema Objects which comply with other drafts of JSON Schema than the default Draft 2020-12 support. Tooling MUST support the OAS dialect schema id, and MAY support additional values of `$schema`.
To allow use of a different default `$schema` value for all Schema Objects contained within an OAS document, a `jsonSchemaDialect` value may be set within the OpenAPI Object. If this default is not set, then the OAS dialect schema id MUST be used for these Schema Objects. The value of `$schema` within a resource root Schema Object always overrides any default.
For standalone JSON Schema documents that do not set `$schema`, or for Schema Objects in OpenAPI description documents that are _not_ [complete documents](#openapi-description-structure), the dialect SHOULD be assumed to be the OAS dialect.
However, for maximum interoperability, it is RECOMMENDED that OpenAPI description authors explicitly set the dialect through `$schema` in such documents.
#### Schema Object Examples
##### Primitive Example
```yaml
type: string
format: email
```
##### Simple Model
```yaml
type: object
required:
- name
properties:
name:
type: string
address:
$ref: '#/components/schemas/Address'
age:
type: integer
format: int32
minimum: 0
```
##### Model with Map/Dictionary Properties
For a simple string to string mapping:
```yaml
type: object
additionalProperties:
type: string
```
For a string to model mapping:
```yaml
type: object
additionalProperties:
$ref: '#/components/schemas/ComplexModel'
```
##### Model with Annotated Enumeration
```yaml
oneOf:
- const: RGB
title: Red, Green, Blue
description: Specify colors with the red, green, and blue additive color model
- const: CMYK
title: Cyan, Magenta, Yellow, Black
description: Specify colors with the cyan, magenta, yellow, and black subtractive color model
```
##### Model with Example
```yaml
type: object
properties:
id:
type: integer
format: int64
name:
type: string
required:
- name
examples:
- name: Puma
id: 1
```
##### Models with Composition
```yaml
components:
schemas:
ErrorModel:
type: object
required:
- message
- code
properties:
message:
type: string
code:
type: integer
minimum: 100
maximum: 600
ExtendedErrorModel:
allOf:
- $ref: '#/components/schemas/ErrorModel'
- type: object
required:
- rootCause
properties:
rootCause:
type: string
```
##### Models with Polymorphism Support
The following example describes a `Pet` model that can represent either a cat or a dog, as distinguished by the `petType` property. Each type of pet has other properties beyond those of the base `Pet` model. An instance without a `petType` property, or with a `petType` property that does not match either `cat` or `dog`, is invalid.
```yaml
components:
schemas:
Pet:
type: object
properties:
name:
type: string
required:
- name
- petType
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
Cat:
description: A pet cat
type: object
properties:
petType:
const: 'cat'
huntingSkill:
type: string
description: The measured skill for hunting
enum:
- clueless
- lazy
- adventurous
- aggressive
required:
- huntingSkill
Dog:
description: A pet dog
type: object
properties:
petType:
const: 'dog'
packSize:
type: integer
format: int32
description: the size of the pack the dog is from
default: 0
minimum: 0
required:
- packSize
```
##### Models with Polymorphism Support and a Discriminator Object
The following example extends the example of the previous section by adding a [Discriminator Object](#discriminator-object) to the `Pet` schema. Note that the Discriminator Object is only a hint to the consumer of the API and does not change the validation outcome of the schema.
```yaml
components:
schemas:
Pet:
type: object
discriminator:
propertyName: petType
mapping:
cat: '#/components/schemas/Cat'
dog: '#/components/schemas/Dog'
properties:
name:
type: string
required:
- name
- petType
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
Cat:
description: A pet cat
type: object
properties:
petType:
const: 'cat'
huntingSkill:
type: string
description: The measured skill for hunting
enum:
- clueless
- lazy
- adventurous
- aggressive
required:
- huntingSkill
Dog:
description: A pet dog
type: object
properties:
petType:
const: 'dog'
packSize:
type: integer
format: int32
description: the size of the pack the dog is from
default: 0
minimum: 0
required:
- petType
- packSize
```
##### Models with Polymorphism Support using `allOf` and a Discriminator Object
It is also possible to describe polymorphic models using `allOf`. The following example uses `allOf` with a [Discriminator Object](#discriminator-object) to describe a polymorphic `Pet` model.
```yaml
components:
schemas:
Pet:
type: object
discriminator:
propertyName: petType
properties:
name:
type: string
petType:
type: string
required:
- name
- petType
Cat: # "Cat" will be used as the discriminating value
description: A representation of a cat
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
properties:
huntingSkill:
type: string
description: The measured skill for hunting
enum:
- clueless
- lazy
- adventurous
- aggressive
required:
- huntingSkill
Dog: # "Dog" will be used as the discriminating value
description: A representation of a dog
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
properties:
packSize:
type: integer
format: int32
description: the size of the pack the dog is from
default: 0
minimum: 0
required:
- packSize
```
##### Generic Data Structure Model
```yaml
components:
schemas:
genericArrayComponent:
$id: fully_generic_array
type: array
items:
$dynamicRef: '#generic-array'
$defs:
allowAll:
$dynamicAnchor: generic-array
numberArray:
$id: array_of_numbers
$ref: fully_generic_array
$defs:
numbersOnly:
$dynamicAnchor: generic-array
type: number
stringArray:
$id: array_of_strings
$ref: fully_generic_array
$defs:
stringsOnly:
$dynamicAnchor: generic-array
type: string
objWithTypedArray:
$id: obj_with_typed_array
type: object
required:
- dataType
- data
properties:
dataType:
enum:
- string
- number
oneOf:
- properties:
dataType:
const: string
data:
$ref: array_of_strings
- properties:
dataType:
const: number
data:
$ref: array_of_numbers
```
### Discriminator Object
When request bodies or response payloads may be one of a number of different schemas, these should use the JSON Schema `anyOf` or `oneOf` keywords to describe the possible schemas (see [Composition and Inheritance](#composition-and-inheritance-polymorphism)).
A polymorphic schema MAY include a Discriminator Object, which defines the name of the property that may be used as a hint for which schema of the `anyOf` or `oneOf`, or which schema that references the current schema in an `allOf`, is expected to validate the structure of the model.
This hint can be used to aid in serialization, deserialization, and validation.
The Discriminator Object does this by implicitly or explicitly associating the possible values of a named property with alternative schemas.
Note that `discriminator` MUST NOT change the validation outcome of the schema.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| propertyName | `string` | **REQUIRED**. The name of the discriminating property in the payload that will hold the discriminating value. The discriminating property MAY be defined as required or optional, but when defined as optional the Discriminator Object MUST include a `defaultMapping` field that specifies which schema is expected to validate the structure of the model when the discriminating property is not present. |
| mapping | Map[`string`, `string`] | An object to hold mappings between payload values and schema names or URI references. |
| defaultMapping | `string` | The schema name or URI reference to a schema that is expected to validate the structure of the model when the discriminating property is not present in the payload or contains a value for which there is no explicit or implicit mapping. |
This object MAY be extended with [Specification Extensions](#specification-extensions).
#### Conditions for Using the Discriminator Object
The Discriminator Object is legal only when using one of the composite keywords `oneOf`, `anyOf`, `allOf`.
In both the `oneOf` and `anyOf` use cases, where those keywords are adjacent to `discriminator`, all possible schemas MUST be listed explicitly.
To avoid redundancy, the discriminator MAY be added to a parent schema definition, and all schemas building on the parent schema via an `allOf` construct may be used as an alternate schema.
The `allOf` form of `discriminator` is _only_ useful for non-validation use cases; validation with the parent schema with this form of `discriminator` _does not_ perform a search for child schemas or use them in validation in any way.
This is because `discriminator` cannot change the validation outcome, and no standard JSON Schema keyword connects the parent schema to the child schemas.
The behavior of any configuration of `oneOf`, `anyOf`, `allOf` and `discriminator` that is not described above is undefined.
#### Options for Mapping Values to Schemas
The value of the property named in `propertyName` is used as the name of the associated schema under the [Components Object](#components-object), _unless_ a `mapping` is present for that value.
The `mapping` entry maps a specific property value to either a different schema component name, or to a schema identified by a URI.
When using implicit or explicit schema component names, inline `oneOf` or `anyOf` subschemas are not considered.
The behavior of a `mapping` value or `defaultMapping` value that is both a valid schema name and a valid relative URI reference is implementation-defined, but it is RECOMMENDED that it be treated as a schema name.
To ensure that an ambiguous value (e.g. `"foo"`) is treated as a relative URI reference by all implementations, authors MUST prefix it with the `"."` path segment (e.g. `"./foo"`).
Mapping keys MUST be string values, but tooling MAY convert response values to strings for comparison.
However, the exact nature of such conversions are implementation-defined.
#### Optional Discriminating Property
When the discriminating property is defined as optional, the [Discriminator Object](#discriminator-object) MUST include a `defaultMapping` field that specifies a schema that is expected to validate the structure of the model when the discriminating property is not present in the payload or contains a value for which there is no explicit or implicit mapping. This allows the schema to still be validated correctly even if the discriminating property is missing.
The primary use case for an optional discriminating property is to allow a schema to be extended with a discriminator without breaking existing clients that do not provide the discriminating property.
When the discriminating property is defined as optional, it is important that each subschema that defines a value for the discriminating property also define the property as required, since this is no longer enforced by the parent schema.
The `defaultMapping` schema is also expected to validate the structure of the model when the discriminating property is present but contains a value for which there is no explicit or implicit mapping. This is typically expressed in the `defaultMapping` schema by excluding any instances with mapped values of the discriminating property, e.g.
```yaml
OtherPet:
type: object
properties:
petType:
not:
enum: ['cat', 'dog']
```
This prevents the `defaultMapping` schema from validating a payload that includes the discriminating property with a mapped discriminating value, which would cause a validation to fail when polymorphism is described using the `oneOf` JSON schema keyword.
#### Examples
For these examples, assume all schemas are in the [entry document](#openapi-description-structure) of the OAD; for handling of `discriminator` in referenced documents see [Resolving Implicit Connections](#resolving-implicit-connections).
In OAS 3.x, a response payload MAY be described to be exactly one of any number of types:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
```
which means a valid payload has to match exactly one of the schemas described by `Cat`, `Dog`, or `Lizard`. Deserialization of a `oneOf` can be a costly operation, as it requires determining which schema matches the payload and thus should be used in deserialization. This problem also exists for `anyOf` schemas. A `discriminator` can be used as a "hint" to improve the efficiency of selection of the matching schema. The [Discriminator Object](#discriminator-object) cannot change the validation result of the `oneOf`, it can only help make the deserialization more efficient and provide better error messaging. We can specify the exact field that tells us which schema is expected to match the instance:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
discriminator:
propertyName: petType
```
The expectation now is that a property with name `petType` _MUST_ be present in the response payload, and the value will correspond to the name of a schema defined in the OpenAPI Description. Thus the response payload:
```json
{
"id": 12345,
"petType": "Cat"
}
```
will indicate that the `Cat` schema is expected to match this payload.
In scenarios where the value of the discriminating property does not match the schema name or implicit mapping is not possible, an optional `mapping` definition can be used:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
- $ref: https://gigantic-server.com/schemas/Monster/schema.json
discriminator:
propertyName: petType
mapping:
dog: '#/components/schemas/Dog'
monster: https://gigantic-server.com/schemas/Monster/schema.json
```
Here the discriminating value of `dog` will map to the schema `#/components/schemas/Dog`, rather than the default (implicit) value of `#/components/schemas/dog`. If the discriminating value does not match an implicit or explicit mapping, no schema can be determined and validation SHOULD fail.
When used in conjunction with the `anyOf` construct, the use of the discriminator can avoid ambiguity for serializers/deserializers where multiple schemas may satisfy a single payload.
When the discriminating property is defined as optional, the Discriminator Object has to include a `defaultMapping` field that specifies a schema of the `anyOf` or `oneOf` is expected to validate the structure of the model when the discriminating property is not present in the payload. This allows the schema to still be validated correctly even if the discriminator property is missing.
For example:
```yaml
MyResponseType:
oneOf:
- $ref: '#/components/schemas/Cat'
- $ref: '#/components/schemas/Dog'
- $ref: '#/components/schemas/Lizard'
- $ref: '#/components/schemas/OtherPet'
discriminator:
propertyName: petType
defaultMapping: OtherPet
OtherPet:
type: object
properties:
petType:
not:
enum: ['Cat', 'Dog', 'Lizard']
```
In this example, if the `petType` property is not present in the payload, or if the value of `petType` is not "Cat", "Dog", or "Lizard", then the payload should validate against the `OtherPet` schema.
This example shows the `allOf` usage, which avoids needing to reference all child schemas in the parent:
```yaml
components:
schemas:
Pet:
type: object
required:
- petType
properties:
petType:
type: string
discriminator:
propertyName: petType
mapping:
dog: Dog
Cat:
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
# all other properties specific to a `Cat`
properties:
name:
type: string
Dog:
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
# all other properties specific to a `Dog`
properties:
bark:
type: string
Lizard:
allOf:
- $ref: '#/components/schemas/Pet'
- type: object
# all other properties specific to a `Lizard`
properties:
lovesRocks:
type: boolean
```
Validated against the `Pet` schema, a payload like this:
```json
{
"petType": "Cat",
"name": "Misty"
}
```
will indicate that the `#/components/schemas/Cat` schema is expected to match. Likewise this payload:
```json
{
"petType": "dog",
"bark": "soft"
}
```
will map to `#/components/schemas/Dog` because the `dog` entry in the `mapping` element maps to `Dog` which is the schema name for `#/components/schemas/Dog`.
### XML Object
A metadata object that allows for more fine-tuned XML model definitions.
When using a Schema Object with XML, if no XML Object is present, the behavior is determined by the XML Object's default field values.
#### Fixed Fields
| Field Name | Type | Description |
| ---- | :----: | ---- |
| nodeType | `string` | One of `element`, `attribute`, `text`, `cdata`, or `none`, as explained under [XML Node Types](#xml-node-types). The default value is `none` if `$ref`, `$dynamicRef`, or `type: "array"` is present in the [Schema Object](#schema-object) containing the XML Object, and `element` otherwise. |
| name | `string` | Sets the name of the element/attribute corresponding to the schema, replacing the name that was inferred as described under [XML Node Names](#xml-node-names). This field SHALL be ignored if the `nodeType` is `text`, `cdata`, or `none`. |
| namespace | `string` | The IRI ([[RFC3987]]) of the namespace definition. Value MUST be in the form of a non-relative IRI. |
| prefix | `string` | The prefix to be used for the [name](#xml-name). |
| attribute | `boolean` | Declares whether the property definition translates to an attribute instead of an element. Default value is `false`. If `nodeType` is present, this field MUST NOT be present.Awesome documentation goes here
--boundary-example ``` In this example, the URI for each part, which also serves as its base URI, comes from the part's `Content-Location` header as specified by RFC2557. Since the Schema Object at `#/components/schemas/Foo` does not contain an `$id`, the reference in its subschema uses the OpenAPI document's base URI, which is taken from the `Content-Location` header of its part within the `multipart/related` format. The resulting reference to `https://example.com/schemas/bar` matches the `Content-Location` header of the second part, which according to RFC2557 allows the reference target to be located within the multipart archive. Similarly, the `url` field of the [External Documentation Object](#external-documentation-object) is resolved against the base URI from `Content-Location`, producing `https://example.com/api/docs.html` which matches the `Content-Location` of the third part. ### Base URI From the Retrieval URI If no base URI is provided from either of the previous sources, the next source is the retrieval URI ([RFC3986](https://tools.ietf.org/html/rfc3986#section-5.1.3)). Assume this document was retrieved from `https://example.com/api/openapis.yaml`: ```yaml openapi: 3.2.1 info: title: Example API version: 1.0 components: requestBodies: Foo: content: application/json: schema: $ref: schemas/foo ``` Assume this document was retrieved from `https://example.com/api/schemas/foo`: ```json { "type": "object", "properties": { "bar": { "type": "string" } } } ``` Resolving the `$ref: schemas/foo` against the retrieval URI of the OpenAPI document produces `https://example.com/api/schemas/foo`, the retrieval URI of the JSON Schema document. ### Application-Specific Default Base URI When constructing an OpenAPI document in memory that does not have a `$self`, or an encapsulating entity, or a retrieval URI, applications can resolve internal (fragment-only) references by assuming a default base URI ([RFC3986](https://tools.ietf.org/html/rfc3986#section-5.1.4)). While this sort of internal resolution can be performed in practice without choosing a base URI, choosing one, such as a URN with a randomly generated UUID (e.g. `urn:uuid:f26cdaad-3193-4398-a838-4ecb7326c4c5`) avoids the need to implement it as a special case. ### Resolving Relative `$self` and `$id` Let's re-consider the first example in this appendix, but with relative URI references for `$self` and `$id`, and retrieval URIs that support that relative usage: Assume that the following is retrieved from `https://staging.example.com/api/openapi`: ```yaml openapi: 3.2.1 $self: /api/openapi info: title: Example API version: 1.0 paths: /foo: get: requestBody: $ref: "shared/foo#/components/requestBodies/Foo" ``` Assume the retrieval URI for the following document is `https://staging.example.com/api/shared/foo`: ```yaml openapi: 3.2.1 $self: /api/shared/foo info: title: Shared components for all APIs version: 1.0 components: requestBodies: Foo: content: application/json: schema: $ref: ../schemas/foo schemas: Foo: $id: /api/schemas/foo properties: bar: $ref: bar Bar: $id: /api/schemas/bar type: string ``` In this example, all of the `$self` and `$id` values are relative URI references consisting of an absolute path. This allows the retrieval URI to set the host (and scheme), in this case `https://staging.example.com`, resulting in the first document's `$self` being `https://staging.example.com/api/openapi`, and the second document's `$self` being `https://staging.example.com/api/shared/foo`, with `$id` values of `https://staging.example.com/api/schemas/foo` and `https://staging.example.com/api/schemas/bar`. Relative `$self` and `$id` values of this sort allow the same set of documents to work when deployed to other hosts, e.g. `https://example.com` (production) or `https://localhost:8080` (local development). ## Appendix G: Parsing and Resolution Guidance Implementations MAY support complete-document parsing in any of the following ways: * Detecting OpenAPI or JSON Schema documents using media types * Detecting OpenAPI documents through the root `openapi` field * Detecting JSON Schema documents through detecting keywords or otherwise successfully parsing the document in accordance with the JSON Schema specification Additional mechanisms can be used to support documents with Objects other than an OpenAPI Object or a Schema Object at the root, but note that the resulting behavior is implementation-defined: * Detecting a document containing a referenceable Object at its root based on the expected type of the reference * Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object ### Warnings Regarding Fragmentary Parsing Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target. In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results. While some implementations support this sort of parsing due to the requirements of past versions of this specification, in version 3.1 and later, the result of parsing fragments in isolation is _undefined_ and likely to contradict the requirements of this specification. While it is possible to structure certain OpenAPI Descriptions to ensure that they will behave correctly when references are parsed as isolated fragments, depending on this is NOT RECOMMENDED. This specification does not explicitly enumerate the conditions under which such behavior is safe and provides no guarantee for continued safety in any future versions of the OAS. ### Conflicts Between Field Types and Reference Contexts JSON or YAML objects within an OAD are interpreted as specific Objects (such as [Operation Objects](#operation-object), [Response Objects](#response-object), [Reference Objects](#reference-object), etc.) based on their context. Depending on how references are arranged, a given JSON or YAML object can be interpreted in multiple different contexts: * As the root object of the [entry document](#openapi-description-structure), which is always interpreted as an OpenAPI Object * As the Object type implied by its parent Object's field within the document * As a reference target, with the Object type matching the reference source's context If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as _different_ Object types, the resulting behavior is _implementation defined_, and MAY be treated as an error if detected. An example would be referencing an empty Schema Object under `#/components/schemas` where a Path Item Object is expected, as an empty object is valid for both types. For maximum interoperability, it is RECOMMENDED that OpenAPI Description authors avoid such scenarios. ### Guidance Regarding Implicit Connections The following Objects and Fields involve the use of implicit connections: | Source | Target | Alternative | | ---- | ---- | ---- | | [Security Requirement Object](#security-requirement-object) `{name}` | [Security Scheme Object](#security-scheme-object) name under the [Components Object](#components-object) | _n/a_ | | [Discriminator Object](#discriminator-object) `mapping` _(implicit, or explicit name syntax)_ | [Schema Object](#schema-object) name under the Components Object | `mapping` _(explicit URI syntax)_ | | [Operation Object](#operation-object) `tags` | [Tag Object](#tag-object) `name` (in the [OpenAPI Object](#openapi-object)'s `tags` array) | _n/a_ | | [Link Object](#link-object) `operationId` | [Operation Object](#operation-object) `operationId` | `operationRef` | An additional implicit connection involves appending the templated URL paths of the [Paths Object](#paths-object) to the appropriate [Server Object](#server-object)'s `url` field. This connection is unambiguous because only the entry document's Paths Object contributes URLs to the described API. The implicit connections in the Security Requirement Object and Discriminator Object rely on the _component name_, which is the name of the property holding the component in the appropriately typed sub-object of the Components Object. For example, the component name of the Schema Object at `#/components/schemas/Foo` is `Foo`. The implicit connection of `tags` in the Operation Object uses the `name` field of Tag Objects, which (like the Components Object) are found under the root OpenAPI Object. This means resolving component names and tag names both depend on starting from the correct OpenAPI Object. For resolving component and tag name connections from a referenced (non-entry) document, it is RECOMMENDED that tools resolve from the entry document, rather than the current document. Resolving component and tag name connections from a referenced (non-entry) document to the entry document as recommended under [Resolving Implicit Connections](#resolving-implicit-connections) allows components and Tag Objects to be defined next to the API's deployment information in the top-level array of Server Objects and treated as an interface for referenced documents to access. For Security Requirement Objects and Discriminator Objects, it is also possible to keep the resolution within the referenced document by using the URI-reference form that these Objects offer. There are no URI-based alternatives for the Operation Object's `tags` field. OAD authors are advised to use external solutions such as the OpenAPI Initiative's Overlay Specification to simulate sharing [Tag Objects](#tag-object) across multiple documents. #### Implicit Connection Resolution Examples This section shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. The behavior for Discriminator Object non-URI mappings and for the Operation Object's `tags` field operate on the same principles. First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document: ```http GET /api/description/openapi HTTP/1.1 Host: www.example.com Accept: application/openapi+json ``` ```json "components": { "securitySchemes": { "MySecurity": { "type": "http", "scheme": "bearer", "bearerFormat": "JWT" } } }, "paths": { "/foo": { "$ref": "other#/components/pathItems/Foo" } } ``` ```http GET /api/description/openapi HTTP/1.1 Host: www.example.com Accept: application/openapi+yaml ``` ```yaml components: securitySchemes: MySecurity: type: http scheme: bearer bearerFormat: JWT paths: /foo: $ref: 'other#/components/pathItems/Foo' ``` This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available: ```http GET /api/description/other HTTP/1.1 Host: www.example.com Accept: application/openapi+json ``` ```json "components": { "securitySchemes": { "MySecurity": { "type": "http", "scheme": "basic" } }, "pathItems": { "Foo": { "get": { "security": [ "MySecurity": [] ] } } } } ``` ```http GET /api/description/other HTTP/1.1 Host: www.example.com Accept: application/openapi+yaml ``` ```yaml components: securitySchemes: MySecurity: type: http scheme: basic pathItems: Foo: get: security: - MySecurity: [] ``` In the `other` document, the referenced path item has a Security Requirement for a Security Scheme, `MySecurity`. The same Security Scheme exists in the original entry document. As outlined in [Resolving Implicit Connections](#resolving-implicit-connections), `MySecurity` is resolved with an [implementation-defined behavior](#undefined-and-implementation-defined-behavior), but the section formally recommends that tools resolve component names from the [entry document](#openapi-description-structure). As with all implementation-defined behavior, it is important to check tool documentation to determine which behavior is supported. OpenAPI-Specification-3.2.1/vitest.config.mjs 0000664 0000000 0000000 00000000376 15250560344 0021035 0 ustar 00root root 0000000 0000000 import { createVitestConfig } from "@oai/build-infra/vitest-config"; export default await createVitestConfig({ globalSetup: ["tests/schema/oas-schema.mjs"], thresholds: process.env.BASE !== "dev" ? { statements: 100, lines: 100 } : {} }); OpenAPI-Specification-3.2.1/yarn.lock 0000664 0000000 0000000 00000436570 15250560344 0017374 0 ustar 00root root 0000000 0000000 # This file is generated by running "yarn install" inside your project. # Manual changes might be lost - proceed with caution! __metadata: version: 10 cacheKey: 10c0 "@alcalzone/ansi-tokenize@npm:^0.3.0": version: 0.3.0 resolution: "@alcalzone/ansi-tokenize@npm:0.3.0" dependencies: ansi-styles: "npm:^6.2.1" is-fullwidth-code-point: "npm:^5.0.0" checksum: 10c0/a6dc3328be7631b42ca76af518c9ecdc2c4edb1b961165db6d570805f5505fdfaf0d11c53c38eb5a5a215844e7a0ece4d1e49e0db5abf049983956be5b95cf4f languageName: node linkType: hard "@babel/helper-string-parser@npm:^7.29.7": version: 7.29.7 resolution: "@babel/helper-string-parser@npm:7.29.7" checksum: 10c0/194bc0f1716e396d5ffde56ad6119745fb9557662c98611590e5e454906783a4ccb21ce93056b8eb69a4909044834e45d96e50ac695bbe9e3221648fe033c06c languageName: node linkType: hard "@babel/helper-validator-identifier@npm:^7.29.7": version: 7.29.7 resolution: "@babel/helper-validator-identifier@npm:7.29.7" checksum: 10c0/4795354e7ae0dcafa72de1cd04ec51252dc1498517170beaf019e03effc5b7bf13c6b21a3949a77e07b8125be7f106ed1131350d8ebd4566ae874094a726d62b languageName: node linkType: hard "@babel/parser@npm:^7.29.7": version: 7.29.8 resolution: "@babel/parser@npm:7.29.8" dependencies: "@babel/types": "npm:^7.29.8" bin: parser: ./bin/babel-parser.js checksum: 10c0/acc890c5e6a6dd40863a47b50bac111d7185ee6fbbe163ebe11d5214854ca2adb901462ad4d718a65090ef84bd2230e9e8ab45a2e0caccc685f1f57ab0bb1e28 languageName: node linkType: hard "@babel/types@npm:^7.29.7, @babel/types@npm:^7.29.8": version: 7.29.8 resolution: "@babel/types@npm:7.29.8" dependencies: "@babel/helper-string-parser": "npm:^7.29.7" "@babel/helper-validator-identifier": "npm:^7.29.7" checksum: 10c0/be7c279f0abf2a086c633e21b49c7ca80275d05283cc5a268b67a708c9914bd0c944f1422b3eb3cb37682a2af5d560abf520ccf9b01b53ecbfe6b71fbc3fdde6 languageName: node linkType: hard "@bcoe/v8-coverage@npm:^1.0.1, @bcoe/v8-coverage@npm:^1.0.2": version: 1.0.2 resolution: "@bcoe/v8-coverage@npm:1.0.2" checksum: 10c0/1eb1dc93cc17fb7abdcef21a6e7b867d6aa99a7ec88ec8207402b23d9083ab22a8011213f04b2cf26d535f1d22dc26139b7929e6c2134c254bd1e14ba5e678c3 languageName: node linkType: hard "@colors/colors@npm:1.5.0": version: 1.5.0 resolution: "@colors/colors@npm:1.5.0" checksum: 10c0/eb42729851adca56d19a08e48d5a1e95efd2a32c55ae0323de8119052be0510d4b7a1611f2abcbf28c044a6c11e6b7d38f99fccdad7429300c37a8ea5fb95b44 languageName: node linkType: hard "@hapi/address@npm:^5.1.1": version: 5.1.1 resolution: "@hapi/address@npm:5.1.1" dependencies: "@hapi/hoek": "npm:^11.0.2" checksum: 10c0/78138effe1e9a36fd12eb42e24adf97f3ca94b9ab1f6db65e3136cf0e5cdbd1578c14adffde18a50d776db2f326a8cb3a16d783b6705b22571a603fa47c8c3d3 languageName: node linkType: hard "@hapi/formula@npm:^3.0.2": version: 3.0.2 resolution: "@hapi/formula@npm:3.0.2" checksum: 10c0/794d30dd13ecc070b9d93e01dacad8175c270f89bcfaa92300f843b7666d915b319d0b792694385d79270c84b52f003a4310f117202303cce3069808751f7a41 languageName: node linkType: hard "@hapi/hoek@npm:^11.0.2, @hapi/hoek@npm:^11.0.7": version: 11.0.7 resolution: "@hapi/hoek@npm:11.0.7" checksum: 10c0/39a4a3ae9526ed66509f6d03c6eb43179a2590df6e98443328c966cfa5e7cbb9d340f61fdbe0afe092662d5377d5a611c3303c808fee26a9c9cfd6bd3737dc1c languageName: node linkType: hard "@hapi/pinpoint@npm:^2.0.1": version: 2.0.1 resolution: "@hapi/pinpoint@npm:2.0.1" checksum: 10c0/b3072f2c57c9fa2e44d85168e253e331324158509e1c45dae2676f31555326410345fd2422f890c41201e2783c5e9bb8c7b0bdcf6abe01079742a943b0c300b9 languageName: node linkType: hard "@hapi/tlds@npm:^1.1.1": version: 1.1.7 resolution: "@hapi/tlds@npm:1.1.7" checksum: 10c0/8429f08c83cd7d324f9b5a577442f78b2d721beba037f8a2a7f652707750800985e0f81302c4b98e9bc784717374005eb3758fb5af6dfb828c62fbb9a4f83a87 languageName: node linkType: hard "@hapi/topo@npm:^6.0.2": version: 6.0.2 resolution: "@hapi/topo@npm:6.0.2" dependencies: "@hapi/hoek": "npm:^11.0.2" checksum: 10c0/5a0079805e9a542bdb852912ce6ed3221ddd0a58569354b3900e165faabe50fb1d2d488067db97c494194835684b055828b6267be3064ac42cf2ce28db02edfc languageName: node linkType: hard "@hyperjump/browser@npm:1.5.0, @hyperjump/browser@npm:^1.3.1": version: 1.5.0 resolution: "@hyperjump/browser@npm:1.5.0" dependencies: "@hyperjump/json-pointer": "npm:^1.1.0" "@hyperjump/uri": "npm:^1.2.0" content-type: "npm:^1.0.5" just-curry-it: "npm:^5.3.0" checksum: 10c0/020a852b3ca841db7b25b42a1e1c5849d7e874d4af1ab7e24f8ab2c4ac20661d5d8ea2a6116db85e1dafc3d9b3c7b935ba20e6d865d9ad1d2ed3a64ff567ac6a languageName: node linkType: hard "@hyperjump/json-pointer@npm:^1.1.0": version: 1.1.2 resolution: "@hyperjump/json-pointer@npm:1.1.2" checksum: 10c0/f5bec5df30d2cefd53e5bece20fab425045fb49d8217380fd81c1c62fc29046d3528fcd0bbcd52e43c49a6fd34a0bf80ea21d399c8b2ffcc9c99ff7842133e77 languageName: node linkType: hard "@hyperjump/json-schema-coverage@npm:1.2.1": version: 1.2.1 resolution: "@hyperjump/json-schema-coverage@npm:1.2.1" dependencies: "@hyperjump/browser": "npm:^1.3.1" "@hyperjump/json-schema": "npm:^1.17.2" "@hyperjump/uri": "npm:^1.3.1" content-type: "npm:^1.0.5" ignore: "npm:^7.0.5" istanbul-lib-coverage: "npm:^3.2.2" istanbul-lib-report: "npm:^3.0.1" istanbul-reports: "npm:^3.1.7" moo: "npm:^0.5.2" pathe: "npm:^2.0.3" picomatch: "npm:^4.0.2" tinyglobby: "npm:^0.2.14" vfile: "npm:^6.0.3" yaml: "npm:^2.8.0" yaml-unist-parser: "npm:^2.0.5" checksum: 10c0/0913d609eafd788dc189534a208811fa22024f79cd428bc7a6925ff16ffaa2d33780bea554927862dbd552106f9a59f3857b28cf129c6a083c401b35b320a354 languageName: node linkType: hard "@hyperjump/json-schema-formats@npm:^1.0.0": version: 1.0.5 resolution: "@hyperjump/json-schema-formats@npm:1.0.5" dependencies: "@hyperjump/uri": "npm:^1.3.2" idn-hostname: "npm:^15.1.2" checksum: 10c0/4844c0240cd51be40f0c939b4b9b5b29ad2a80424ca4f02053b85c2e3f9827e3659806edad7ed8145f7b39f2855eb4340c15e0040c5cc0858103f01426a6d646 languageName: node linkType: hard "@hyperjump/json-schema@npm:1.17.8, @hyperjump/json-schema@npm:^1.17.2": version: 1.17.8 resolution: "@hyperjump/json-schema@npm:1.17.8" dependencies: "@hyperjump/json-pointer": "npm:^1.1.0" "@hyperjump/json-schema-formats": "npm:^1.0.0" "@hyperjump/pact": "npm:^1.2.0" "@hyperjump/uri": "npm:^1.2.0" content-type: "npm:^1.0.4" json-stringify-deterministic: "npm:^1.0.12" just-curry-it: "npm:^5.3.0" uuid: "npm:^14.0.0" peerDependencies: "@hyperjump/browser": ^1.1.0 checksum: 10c0/90f2455a5966ad73a291d9945eb2ad82a6fa96f35b7992651e76bfc03e8fc2843e40f4e2956e4510005839478fc8414064c2ab324d6fd37e033e5214e63cefa8 languageName: node linkType: hard "@hyperjump/pact@npm:^1.2.0": version: 1.4.0 resolution: "@hyperjump/pact@npm:1.4.0" checksum: 10c0/fd56c5d5cb314368a12b8cd6603fae19639b7f19444ba3d55cb0dbf92d4eddcabe97edb84b0f374ed0bb754787bbe63599aed654175115a177cad2b5d396b068 languageName: node linkType: hard "@hyperjump/uri@npm:^1.2.0, @hyperjump/uri@npm:^1.3.1, @hyperjump/uri@npm:^1.3.2": version: 1.3.5 resolution: "@hyperjump/uri@npm:1.3.5" checksum: 10c0/d325c93ca66f8f355b30a2423c1b5f0cb57de84ef0399bc9b929e137c55cdfda5c88a5def982aa584bc024e320a9c338dec230233a383ac14f697aa375ac5b74 languageName: node linkType: hard "@isaacs/fs-minipass@npm:^4.0.0": version: 4.0.1 resolution: "@isaacs/fs-minipass@npm:4.0.1" dependencies: minipass: "npm:^7.0.4" checksum: 10c0/c25b6dc1598790d5b55c0947a9b7d111cfa92594db5296c3b907e2f533c033666f692a3939eadac17b1c7c40d362d0b0635dc874cbfe3e70db7c2b07cc97a5d2 languageName: node linkType: hard "@istanbuljs/schema@npm:^0.1.2, @istanbuljs/schema@npm:^0.1.3": version: 0.1.6 resolution: "@istanbuljs/schema@npm:0.1.6" checksum: 10c0/bb0d370bf3dd454d2f37f1bccb8921e2da99adacef2da56ef47850e25d7a4de69cf639ead8c189755aef38921369024b4afea3535a5c2ac9082b3e1171bcbc3a languageName: node linkType: hard "@jridgewell/resolve-uri@npm:^3.1.0": version: 3.1.2 resolution: "@jridgewell/resolve-uri@npm:3.1.2" checksum: 10c0/d502e6fb516b35032331406d4e962c21fe77cdf1cbdb49c6142bcbd9e30507094b18972778a6e27cbad756209cfe34b1a27729e6fa08a2eb92b33943f680cf1e languageName: node linkType: hard "@jridgewell/sourcemap-codec@npm:^1.4.14, @jridgewell/sourcemap-codec@npm:^1.5.5": version: 1.5.5 resolution: "@jridgewell/sourcemap-codec@npm:1.5.5" checksum: 10c0/f9e538f302b63c0ebc06eecb1dd9918dd4289ed36147a0ddce35d6ea4d7ebbda243cda7b2213b6a5e1d8087a298d5cf630fb2bd39329cdecb82017023f6081a0 languageName: node linkType: hard "@jridgewell/trace-mapping@npm:0.3.31, @jridgewell/trace-mapping@npm:^0.3.12, @jridgewell/trace-mapping@npm:^0.3.31": version: 0.3.31 resolution: "@jridgewell/trace-mapping@npm:0.3.31" dependencies: "@jridgewell/resolve-uri": "npm:^3.1.0" "@jridgewell/sourcemap-codec": "npm:^1.4.14" checksum: 10c0/4b30ec8cd56c5fd9a661f088230af01e0c1a3888d11ffb6b47639700f71225be21d1f7e168048d6d4f9449207b978a235c07c8f15c07705685d16dc06280e9d9 languageName: node linkType: hard "@nodelib/fs.scandir@npm:2.1.5": version: 2.1.5 resolution: "@nodelib/fs.scandir@npm:2.1.5" dependencies: "@nodelib/fs.stat": "npm:2.0.5" run-parallel: "npm:^1.1.9" checksum: 10c0/732c3b6d1b1e967440e65f284bd06e5821fedf10a1bea9ed2bb75956ea1f30e08c44d3def9d6a230666574edbaf136f8cfd319c14fd1f87c66e6a44449afb2eb languageName: node linkType: hard "@nodelib/fs.stat@npm:2.0.5, @nodelib/fs.stat@npm:^2.0.2": version: 2.0.5 resolution: "@nodelib/fs.stat@npm:2.0.5" checksum: 10c0/88dafe5e3e29a388b07264680dc996c17f4bda48d163a9d4f5c1112979f0ce8ec72aa7116122c350b4e7976bc5566dc3ddb579be1ceaacc727872eb4ed93926d languageName: node linkType: hard "@nodelib/fs.walk@npm:^1.2.3": version: 1.2.8 resolution: "@nodelib/fs.walk@npm:1.2.8" dependencies: "@nodelib/fs.scandir": "npm:2.1.5" fastq: "npm:^1.6.0" checksum: 10c0/db9de047c3bb9b51f9335a7bb46f4fcfb6829fb628318c12115fbaf7d369bfce71c15b103d1fc3b464812d936220ee9bc1c8f762d032c9f6be9acc99249095b1 languageName: node linkType: hard "@oai/build-infra@git+https://github.com/OAI/build-infra.git#main": version: 1.0.1 resolution: "@oai/build-infra@https://github.com/OAI/build-infra.git#commit=c72e3893ad47965e2487df3e037e4e86ef0b36b9" dependencies: "@hyperjump/browser": "npm:1.5.0" "@hyperjump/json-schema": "npm:1.17.8" "@hyperjump/json-schema-coverage": "npm:1.2.1" "@umbrelladocs/linkspector": "npm:0.5.6" "@vitest/coverage-v8": "npm:5.0.0" c8: "npm:12.0.0" cheerio: "npm:1.2.0" content-type: "npm:3.0.0" highlight.js: "npm:11.12.0" markdown-it: "npm:15.0.1" markdownlint-cli2: "npm:0.23.2" respec: "npm:37.3.6" semver: "npm:7.8.5" vite: "npm:8.2.2" vitest: "npm:5.0.0" yaml: "npm:2.9.0" yargs: "npm:18.1.0" dependenciesMeta: puppeteer: built: true bin: oai-spec-adjust-release-branch: ./bin/oai-spec-adjust-release-branch oai-spec-build: ./bin/oai-spec-build oai-spec-format-markdown: ./bin/oai-spec-format-markdown oai-spec-publish-schemas: ./bin/oai-spec-publish-schemas oai-spec-start-release: ./bin/oai-spec-start-release oai-spec-test: ./bin/oai-spec-test oai-spec-validate-markdown: ./bin/oai-spec-validate-markdown checksum: 10c0/cbe8ec26d0314707e4f7aa733192efa57ca01905499416daf16c1a6076ab24a30f8bc09946d679519132696ed587c3300024878ac5e3a53f8604f6a44854b5fc languageName: node linkType: hard "@oxc-project/types@npm:=0.149.0": version: 0.149.0 resolution: "@oxc-project/types@npm:0.149.0" checksum: 10c0/f91ff8101300ce5a29fbfc57bdaafd9c1c9d3d9b46c63093f437c479d047042eb615cb6c3ddac91a0d289701ce60c365632866a85d0f1e0d159b20180115187e languageName: node linkType: hard "@puppeteer/browsers@npm:3.2.1": version: 3.2.1 resolution: "@puppeteer/browsers@npm:3.2.1" dependencies: modern-tar: "npm:^0.8.0" yargs: "npm:^18.0.0" peerDependencies: proxy-agent: ">=8.0.1" yauzl: ^2.10.0 || ^3.4.0 peerDependenciesMeta: proxy-agent: optional: true yauzl: optional: true bin: browsers: lib/main-cli.js checksum: 10c0/e70a89661236a3d8e9103b422bd52f7799c640b452fa4bbebac2ba1389330d7936281cdd135041dbaad2209cc42a21bcbf5f758a49759d4c05565f677c6d0ece languageName: node linkType: hard "@puppeteer/browsers@npm:3.2.2": version: 3.2.2 resolution: "@puppeteer/browsers@npm:3.2.2" dependencies: modern-tar: "npm:^0.8.4" yargs: "npm:^18.0.0" peerDependencies: proxy-agent: ">=8.0.1" yauzl: ^2.10.0 || ^3.4.0 peerDependenciesMeta: proxy-agent: optional: true yauzl: optional: true bin: browsers: lib/main-cli.js checksum: 10c0/c26a8c4669ccc5a3a29a1879fd9f68d6af88ea09d6678f0d4405950fa5a13298badbd59c69a777418e60f62898777ec0859fff01e2912568f4d5b660d6dd46f3 languageName: node linkType: hard "@rolldown/binding-android-arm-eabi@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-android-arm-eabi@npm:1.2.8" conditions: os=android & cpu=arm languageName: node linkType: hard "@rolldown/binding-android-arm64@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-android-arm64@npm:1.2.8" conditions: os=android & cpu=arm64 languageName: node linkType: hard "@rolldown/binding-darwin-arm64@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-darwin-arm64@npm:1.2.8" conditions: os=darwin & cpu=arm64 languageName: node linkType: hard "@rolldown/binding-darwin-x64@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-darwin-x64@npm:1.2.8" conditions: os=darwin & cpu=x64 languageName: node linkType: hard "@rolldown/binding-freebsd-x64@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-freebsd-x64@npm:1.2.8" conditions: os=freebsd & cpu=x64 languageName: node linkType: hard "@rolldown/binding-linux-arm-gnueabihf@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-arm-gnueabihf@npm:1.2.8" conditions: os=linux & cpu=arm languageName: node linkType: hard "@rolldown/binding-linux-arm64-gnu@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-arm64-gnu@npm:1.2.8" conditions: os=linux & cpu=arm64 & libc=glibc languageName: node linkType: hard "@rolldown/binding-linux-arm64-musl@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-arm64-musl@npm:1.2.8" conditions: os=linux & cpu=arm64 & libc=musl languageName: node linkType: hard "@rolldown/binding-linux-ppc64-gnu@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-ppc64-gnu@npm:1.2.8" conditions: os=linux & cpu=ppc64 & libc=glibc languageName: node linkType: hard "@rolldown/binding-linux-s390x-gnu@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-s390x-gnu@npm:1.2.8" conditions: os=linux & cpu=s390x & libc=glibc languageName: node linkType: hard "@rolldown/binding-linux-x64-gnu@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-x64-gnu@npm:1.2.8" conditions: os=linux & cpu=x64 & libc=glibc languageName: node linkType: hard "@rolldown/binding-linux-x64-musl@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-linux-x64-musl@npm:1.2.8" conditions: os=linux & cpu=x64 & libc=musl languageName: node linkType: hard "@rolldown/binding-openharmony-arm64@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-openharmony-arm64@npm:1.2.8" conditions: os=openharmony & cpu=arm64 languageName: node linkType: hard "@rolldown/binding-win32-arm64-msvc@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-win32-arm64-msvc@npm:1.2.8" conditions: os=win32 & cpu=arm64 languageName: node linkType: hard "@rolldown/binding-win32-x64-msvc@npm:1.2.8": version: 1.2.8 resolution: "@rolldown/binding-win32-x64-msvc@npm:1.2.8" conditions: os=win32 & cpu=x64 languageName: node linkType: hard "@rolldown/pluginutils@npm:^1.0.0": version: 1.0.1 resolution: "@rolldown/pluginutils@npm:1.0.1" checksum: 10c0/99d9b06d90196823e4d8c841f258db7a16e5dbba5824a2962b05d907b79f1ba929d56f22dd744fd530936e568c865ee56a719dc31e57e13bc0a8eb4764a8d8dd languageName: node linkType: hard "@sindresorhus/merge-streams@npm:^4.0.0": version: 4.0.0 resolution: "@sindresorhus/merge-streams@npm:4.0.0" checksum: 10c0/482ee543629aa1933b332f811a1ae805a213681ecdd98c042b1c1b89387df63e7812248bb4df3910b02b3cc5589d3d73e4393f30e197c9dde18046ccd471fc6b languageName: node linkType: hard "@standard-schema/spec@npm:^1.1.0": version: 1.1.0 resolution: "@standard-schema/spec@npm:1.1.0" checksum: 10c0/d90f55acde4b2deb983529c87e8025fa693de1a5e8b49ecc6eb84d1fd96328add0e03d7d551442156c7432fd78165b2c26ff561b970a9a881f046abb78d6a526 languageName: node linkType: hard "@types/chai@npm:^5.2.2": version: 5.2.3 resolution: "@types/chai@npm:5.2.3" dependencies: "@types/deep-eql": "npm:*" assertion-error: "npm:^2.0.1" checksum: 10c0/e0ef1de3b6f8045a5e473e867c8565788c444271409d155588504840ad1a53611011f85072188c2833941189400228c1745d78323dac13fcede9c2b28bacfb2f languageName: node linkType: hard "@types/debug@npm:^4.0.0": version: 4.1.13 resolution: "@types/debug@npm:4.1.13" dependencies: "@types/ms": "npm:*" checksum: 10c0/e5e124021bbdb23a82727eee0a726ae0fc8a3ae1f57253cbcc47497f259afb357de7f6941375e773e1abbfa1604c1555b901a409d762ec2bb4c1612131d4afb7 languageName: node linkType: hard "@types/deep-eql@npm:*": version: 4.0.2 resolution: "@types/deep-eql@npm:4.0.2" checksum: 10c0/bf3f811843117900d7084b9d0c852da9a044d12eb40e6de73b552598a6843c21291a8a381b0532644574beecd5e3491c5ff3a0365ab86b15d59862c025384844 languageName: node linkType: hard "@types/estree@npm:^1.0.0": version: 1.0.9 resolution: "@types/estree@npm:1.0.9" checksum: 10c0/3ad3286ca2988cd550dafb8f2ad599c8474868e954fa601a36655bdfefd8039f7c714b8c1c7f2ae219ffbd58bd4660e66fa7479a0120fc02d4777057d4865387 languageName: node linkType: hard "@types/istanbul-lib-coverage@npm:^2.0.1": version: 2.0.6 resolution: "@types/istanbul-lib-coverage@npm:2.0.6" checksum: 10c0/3948088654f3eeb45363f1db158354fb013b362dba2a5c2c18c559484d5eb9f6fd85b23d66c0a7c2fcfab7308d0a585b14dadaca6cc8bf89ebfdc7f8f5102fb7 languageName: node linkType: hard "@types/katex@npm:^0.16.0": version: 0.16.8 resolution: "@types/katex@npm:0.16.8" checksum: 10c0/0661609353f4f5e62bd2dc78da99e842761c6474b19f2268b195bbe9dbf20e6f766a31155d79eec2e7c3eff4e7eba4b30f4f519e9c6a11c75bb45e257a2ddb69 languageName: node linkType: hard "@types/mdast@npm:^4.0.0": version: 4.0.4 resolution: "@types/mdast@npm:4.0.4" dependencies: "@types/unist": "npm:*" checksum: 10c0/84f403dbe582ee508fd9c7643ac781ad8597fcbfc9ccb8d4715a2c92e4545e5772cbd0dbdf18eda65789386d81b009967fdef01b24faf6640f817287f54d9c82 languageName: node linkType: hard "@types/ms@npm:*": version: 2.1.0 resolution: "@types/ms@npm:2.1.0" checksum: 10c0/5ce692ffe1549e1b827d99ef8ff71187457e0eb44adbae38fdf7b9a74bae8d20642ee963c14516db1d35fa2652e65f47680fdf679dcbde52bbfadd021f497225 languageName: node linkType: hard "@types/unist@npm:*, @types/unist@npm:^3.0.0": version: 3.0.3 resolution: "@types/unist@npm:3.0.3" checksum: 10c0/2b1e4adcab78388e088fcc3c0ae8700f76619dbcb4741d7d201f87e2cb346bfc29a89003cfea2d76c996e1061452e14fcd737e8b25aacf949c1f2d6b2bc3dd60 languageName: node linkType: hard "@types/unist@npm:^2.0.0": version: 2.0.11 resolution: "@types/unist@npm:2.0.11" checksum: 10c0/24dcdf25a168f453bb70298145eb043cfdbb82472db0bc0b56d6d51cd2e484b9ed8271d4ac93000a80da568f2402e9339723db262d0869e2bf13bc58e081768d languageName: node linkType: hard "@umbrelladocs/linkspector@npm:0.5.6": version: 0.5.6 resolution: "@umbrelladocs/linkspector@npm:0.5.6" dependencies: "@umbrelladocs/rdformat-validator": "npm:^1.0.1" cli-table3: "npm:^0.6.5" commander: "npm:^15.0.0" figures: "npm:^6.1.0" github-slugger: "npm:^2.0.0" glob: "npm:^13.0.6" ignore: "npm:^7.0.5" ink: "npm:^7.1.0" joi: "npm:^18.2.3" js-yaml: "npm:^5.2.0" kleur: "npm:^4.1.5" ora: "npm:^9.4.1" puppeteer: "npm:^25.2.1" react: "npm:^19.2.7" remark-gfm: "npm:^4.0.1" remark-parse: "npm:^11.0.0" unified: "npm:^11.0.5" unist-util-visit: "npm:^5.1.0" bin: linkspector: index.js checksum: 10c0/427ecb7ab6cfc84e8eac6741b844eb960bf8f3b5fb82caea753fcaecebe1e05159c3456dd05b6336fd1e2b4587018b5e37f41a5c412ef80bfef904be90777690 languageName: node linkType: hard "@umbrelladocs/rdformat-validator@npm:^1.0.1": version: 1.0.1 resolution: "@umbrelladocs/rdformat-validator@npm:1.0.1" dependencies: commander: "npm:^14.0.0" bin: rdformat-validator: bin/rdformat-validator.js checksum: 10c0/dd2f7310af9d82f805080f1919e8dbffe89a8ab91269701c1da3223c670764f96ac0ae0d048f98c25e826f2c52023497207ddc9caf4bbf377af38286bdf02b2b languageName: node linkType: hard "@vitest/coverage-v8@npm:5.0.0": version: 5.0.0 resolution: "@vitest/coverage-v8@npm:5.0.0" dependencies: "@bcoe/v8-coverage": "npm:^1.0.2" "@vitest/istanbul-lib-coverage": "npm:^1.0.0" "@vitest/istanbul-lib-report": "npm:^1.0.0" ast-v8-to-istanbul: "npm:^1.0.5" magicast: "npm:^0.5.4" obug: "npm:^2.1.4" std-env: "npm:^4.2.0" tinyrainbow: "npm:^3.1.1" peerDependencies: "@vitest/browser": 5.0.0 vitest: 5.0.0 peerDependenciesMeta: "@vitest/browser": optional: true checksum: 10c0/6d7f102af8f11f69df21ba343b4d101fbdb39ce5568bd2686c72cdf44e03934889328df297ebe4e12dbe1bc5e0a6d565bb9dfaf2fbca1958bf5e7770c7dc9675 languageName: node linkType: hard "@vitest/istanbul-lib-coverage@npm:1.0.1, @vitest/istanbul-lib-coverage@npm:^1.0.0": version: 1.0.1 resolution: "@vitest/istanbul-lib-coverage@npm:1.0.1" checksum: 10c0/5259767db6c748a018c39554951e19818268fb6f72f74b74d2370471c7d83df990c3371247caea7d38f8e315df6dd461427dc242a1e7f5071e4b28863524f354 languageName: node linkType: hard "@vitest/istanbul-lib-report@npm:^1.0.0": version: 1.0.1 resolution: "@vitest/istanbul-lib-report@npm:1.0.1" dependencies: "@vitest/istanbul-lib-coverage": "npm:1.0.1" checksum: 10c0/1a76d4cd4c6284da0b897230d672769a5191235b3a0df41a3c861e3e12659d1790012705df6bad0f540e3f14b7b017f3611f99c9b9eb96972f8b55a3fb9270fe languageName: node linkType: hard "@vitest/mocker@npm:5.0.0": version: 5.0.0 resolution: "@vitest/mocker@npm:5.0.0" dependencies: "@jridgewell/trace-mapping": "npm:0.3.31" "@vitest/spy": "npm:5.0.0" estree-walker: "npm:^3.0.3" magic-string: "npm:^1.2.3" peerDependencies: msw: ^2.4.9 vite: ^6.0.0 || ^7.0.0 || ^8.0.0 peerDependenciesMeta: msw: optional: true vite: optional: true checksum: 10c0/b1dde0ef270e8f9401204cb19c798114de416c3cf31e1d44d0029c4281b33e9a799251e3015aaaa2bdf5858c97a56857812dcf1e04dcfd4ebeedf194e6bcf3e6 languageName: node linkType: hard "@vitest/spy@npm:5.0.0": version: 5.0.0 resolution: "@vitest/spy@npm:5.0.0" checksum: 10c0/7521b4ef803bc89974a738cead7d3fcd789af805f3ea3f496108fc802b2bc09b22fe8e7a3cc0be3f92b647427aea528657e3e87dd0201e432f56e62f84f25ba8 languageName: node linkType: hard "abbrev@npm:^5.0.0": version: 5.0.0 resolution: "abbrev@npm:5.0.0" checksum: 10c0/8e88f5c798ea4562d28c5a3e9ad69e3879890bc5d695d8f2dffb8609be4c890aacc8f80ef4553fdd2c6a62d70c2ce8bc57b38074e383beb7487bdafa9ed42ea5 languageName: node linkType: hard "ansi-escapes@npm:^7.3.0": version: 7.3.0 resolution: "ansi-escapes@npm:7.3.0" dependencies: environment: "npm:^1.0.0" checksum: 10c0/068961d99f0ef28b661a4a9f84a5d645df93ccf3b9b93816cc7d46bbe1913321d4cdf156bb842a4e1e4583b7375c631fa963efb43001c4eb7ff9ab8f78fc0679 languageName: node linkType: hard "ansi-regex@npm:^5.0.1": version: 5.0.1 resolution: "ansi-regex@npm:5.0.1" checksum: 10c0/9a64bb8627b434ba9327b60c027742e5d17ac69277960d041898596271d992d4d52ba7267a63ca10232e29f6107fc8a835f6ce8d719b88c5f8493f8254813737 languageName: node linkType: hard "ansi-regex@npm:^6.2.2": version: 6.3.0 resolution: "ansi-regex@npm:6.3.0" checksum: 10c0/bc047786d0531f1f22d1e22e9863e8554488a399f1ee5270b753efa6de938a788d27456f2b256770f11fdd8b1e847483bc1b55ddc2b3ffe82ec45c875292c651 languageName: node linkType: hard "ansi-styles@npm:^6.2.1, ansi-styles@npm:^6.2.3": version: 6.2.3 resolution: "ansi-styles@npm:6.2.3" checksum: 10c0/23b8a4ce14e18fb854693b95351e286b771d23d8844057ed2e7d083cd3e708376c3323707ec6a24365f7d7eda3ca00327fe04092e29e551499ec4c8b7bfac868 languageName: node linkType: hard "argparse@npm:^2.0.1": version: 2.0.1 resolution: "argparse@npm:2.0.1" checksum: 10c0/c5640c2d89045371c7cedd6a70212a04e360fd34d6edeae32f6952c63949e3525ea77dbec0289d8213a99bbaeab5abfa860b5c12cf88a2e6cf8106e90dd27a7e languageName: node linkType: hard "argparse@npm:^3.0.0": version: 3.0.0 resolution: "argparse@npm:3.0.0" checksum: 10c0/76219209d7a4642f063278d93b37602df8a39c9e810e69b1b650b0bd6b847b5e880f216e4e2c2fa08116436de9ecd8d7026b3cddfc5668a8a4e69348ed03bcc8 languageName: node linkType: hard "assertion-error@npm:^2.0.1": version: 2.0.1 resolution: "assertion-error@npm:2.0.1" checksum: 10c0/bbbcb117ac6480138f8c93cf7f535614282dea9dc828f540cdece85e3c665e8f78958b96afac52f29ff883c72638e6a87d469ecc9fe5bc902df03ed24a55dba8 languageName: node linkType: hard "ast-v8-to-istanbul@npm:^1.0.5": version: 1.0.6 resolution: "ast-v8-to-istanbul@npm:1.0.6" dependencies: "@jridgewell/trace-mapping": "npm:^0.3.31" estree-walker: "npm:^3.0.3" js-tokens: "npm:^10.0.0" checksum: 10c0/d0f5c45f3c3054d2f142f460df3dfb26a17b910e1ca95f3d379fc505877c7610baba635c4a7e6f8c837d6ad0f0aa0e94daee4252200cb3d42f420e518a8c5d3e languageName: node linkType: hard "auto-bind@npm:^5.0.1": version: 5.0.1 resolution: "auto-bind@npm:5.0.1" checksum: 10c0/a703375350ea7b6e92405d8e6bcc6dbfb84b0d7c7172b33e5788a7593929a18227999ff9aa9c32436741d06d021e6672457b1cec73287efe3fab95cff6627eaf languageName: node linkType: hard "bail@npm:^2.0.0": version: 2.0.2 resolution: "bail@npm:2.0.2" checksum: 10c0/25cbea309ef6a1f56214187004e8f34014eb015713ea01fa5b9b7e9e776ca88d0fdffd64143ac42dc91966c915a4b7b683411b56e14929fad16153fc026ffb8b languageName: node linkType: hard "balanced-match@npm:^4.0.2": version: 4.0.4 resolution: "balanced-match@npm:4.0.4" checksum: 10c0/07e86102a3eb2ee2a6a1a89164f29d0dbaebd28f2ca3f5ca786f36b8b23d9e417eb3be45a4acf754f837be5ac0a2317de90d3fcb7f4f4dc95720a1f36b26a17b languageName: node linkType: hard "boolbase@npm:^1.0.0": version: 1.0.0 resolution: "boolbase@npm:1.0.0" checksum: 10c0/e4b53deb4f2b85c52be0e21a273f2045c7b6a6ea002b0e139c744cb6f95e9ec044439a52883b0d74dedd1ff3da55ed140cfdddfed7fb0cccbed373de5dce1bcf languageName: node linkType: hard "brace-expansion@npm:^5.0.8": version: 5.0.9 resolution: "brace-expansion@npm:5.0.9" dependencies: balanced-match: "npm:^4.0.2" checksum: 10c0/3dea38884a1c3c8b1c9c44a7402a0c76fca460f70cffb3127242b0b4cbf4472019e022ade021eec44838ff19f1dac2625dfd11dd459d7e1e055b0698a8d52fec languageName: node linkType: hard "braces@npm:^3.0.3": version: 3.0.3 resolution: "braces@npm:3.0.3" dependencies: fill-range: "npm:^7.1.1" checksum: 10c0/7c6dfd30c338d2997ba77500539227b9d1f85e388a5f43220865201e407e076783d0881f2d297b9f80951b4c957fcf0b51c1d2d24227631643c3f7c284b0aa04 languageName: node linkType: hard "c8@npm:12.0.0": version: 12.0.0 resolution: "c8@npm:12.0.0" dependencies: "@bcoe/v8-coverage": "npm:^1.0.1" "@istanbuljs/schema": "npm:^0.1.3" find-up: "npm:^5.0.0" foreground-child: "npm:^3.1.1" istanbul-lib-coverage: "npm:^3.2.0" istanbul-lib-report: "npm:^3.0.1" istanbul-reports: "npm:^3.1.6" test-exclude: "npm:^8.0.0" v8-to-istanbul: "npm:^9.0.0" yargs: "npm:^18.0.0" yargs-parser: "npm:^21.1.1" peerDependencies: monocart-coverage-reports: ^2 peerDependenciesMeta: monocart-coverage-reports: optional: true bin: c8: bin/c8.js checksum: 10c0/bd6da501c223d8700915a91e67be4c59830718ebd15125b82348cda6e3d816632539c9047b1b0b2cbc878596448e8c724e539568be23926deb95693e703f35f7 languageName: node linkType: hard "ccount@npm:^2.0.0": version: 2.0.1 resolution: "ccount@npm:2.0.1" checksum: 10c0/3939b1664390174484322bc3f45b798462e6c07ee6384cb3d645e0aa2f318502d174845198c1561930e1d431087f74cf1fe291ae9a4722821a9f4ba67e574350 languageName: node linkType: hard "chai@npm:^6.2.2": version: 6.2.2 resolution: "chai@npm:6.2.2" checksum: 10c0/e6c69e5f0c11dffe6ea13d0290936ebb68fcc1ad688b8e952e131df6a6d5797d5e860bc55cef1aca2e950c3e1f96daf79e9d5a70fb7dbaab4e46355e2635ed53 languageName: node linkType: hard "chalk@npm:^5.6.2": version: 5.6.2 resolution: "chalk@npm:5.6.2" checksum: 10c0/99a4b0f0e7991796b1e7e3f52dceb9137cae2a9dfc8fc0784a550dc4c558e15ab32ed70b14b21b52beb2679b4892b41a0aa44249bcb996f01e125d58477c6976 languageName: node linkType: hard "character-entities-legacy@npm:^3.0.0": version: 3.0.0 resolution: "character-entities-legacy@npm:3.0.0" checksum: 10c0/ec4b430af873661aa754a896a2b55af089b4e938d3d010fad5219299a6b6d32ab175142699ee250640678cd64bdecd6db3c9af0b8759ab7b155d970d84c4c7d1 languageName: node linkType: hard "character-entities@npm:^2.0.0": version: 2.0.2 resolution: "character-entities@npm:2.0.2" checksum: 10c0/b0c645a45bcc90ff24f0e0140f4875a8436b8ef13b6bcd31ec02cfb2ca502b680362aa95386f7815bdc04b6464d48cf191210b3840d7c04241a149ede591a308 languageName: node linkType: hard "character-reference-invalid@npm:^2.0.0": version: 2.0.1 resolution: "character-reference-invalid@npm:2.0.1" checksum: 10c0/2ae0dec770cd8659d7e8b0ce24392d83b4c2f0eb4a3395c955dce5528edd4cc030a794cfa06600fcdd700b3f2de2f9b8e40e309c0011c4180e3be64a0b42e6a1 languageName: node linkType: hard "cheerio-select@npm:^2.1.0": version: 2.1.0 resolution: "cheerio-select@npm:2.1.0" dependencies: boolbase: "npm:^1.0.0" css-select: "npm:^5.1.0" css-what: "npm:^6.1.0" domelementtype: "npm:^2.3.0" domhandler: "npm:^5.0.3" domutils: "npm:^3.0.1" checksum: 10c0/2242097e593919dba4aacb97d7b8275def8b9ec70b00aa1f43335456870cfc9e284eae2080bdc832ed232dabb9eefcf56c722d152da4a154813fb8814a55d282 languageName: node linkType: hard "cheerio@npm:1.2.0": version: 1.2.0 resolution: "cheerio@npm:1.2.0" dependencies: cheerio-select: "npm:^2.1.0" dom-serializer: "npm:^2.0.0" domhandler: "npm:^5.0.3" domutils: "npm:^3.2.2" encoding-sniffer: "npm:^0.2.1" htmlparser2: "npm:^10.1.0" parse5: "npm:^7.3.0" parse5-htmlparser2-tree-adapter: "npm:^7.1.0" parse5-parser-stream: "npm:^7.1.2" undici: "npm:^7.19.0" whatwg-mimetype: "npm:^4.0.0" checksum: 10c0/91a566aabfa9962f28056045bb7d92d79c0f8f3abb1fb86a852a9d1760556adddeb01a36b6f08fa7c133282375d387ae450a181a659e76c6a64016c30cc3f611 languageName: node linkType: hard "chownr@npm:^3.0.0": version: 3.0.0 resolution: "chownr@npm:3.0.0" checksum: 10c0/43925b87700f7e3893296c8e9c56cc58f926411cce3a6e5898136daaf08f08b9a8eb76d37d3267e707d0dcc17aed2e2ebdf5848c0c3ce95cf910a919935c1b10 languageName: node linkType: hard "chromium-bidi@npm:17.0.2": version: 17.0.2 resolution: "chromium-bidi@npm:17.0.2" dependencies: mitt: "npm:^3.0.1" zod: "npm:^3.24.1" peerDependencies: devtools-protocol: "*" checksum: 10c0/cc1fcbdf2309f2f0083096c78a299342918c6dc8e80158487aada8e2ee73160ed7301bb54c5520274e4514f2a14f05e45d730a536e0a95f2e204dd8bf42eebee languageName: node linkType: hard "cli-boxes@npm:^4.0.1": version: 4.0.1 resolution: "cli-boxes@npm:4.0.1" checksum: 10c0/a61d28caf46b35ffbc1797736ccdbd6af37357b08dc773ae874c9645eec063ec4fb55225304109979d3419d560acf572d78c743b2cf78b7c50e8a18b30a2bb59 languageName: node linkType: hard "cli-cursor@npm:^4.0.0": version: 4.0.0 resolution: "cli-cursor@npm:4.0.0" dependencies: restore-cursor: "npm:^4.0.0" checksum: 10c0/e776e8c3c6727300d0539b0d25160b2bb56aed1a63942753ba1826b012f337a6f4b7ace3548402e4f2f13b5e16bfd751be672c44b203205e7eca8be94afec42c languageName: node linkType: hard "cli-cursor@npm:^5.0.0": version: 5.0.0 resolution: "cli-cursor@npm:5.0.0" dependencies: restore-cursor: "npm:^5.0.0" checksum: 10c0/7ec62f69b79f6734ab209a3e4dbdc8af7422d44d360a7cb1efa8a0887bbe466a6e625650c466fe4359aee44dbe2dc0b6994b583d40a05d0808a5cb193641d220 languageName: node linkType: hard "cli-spinners@npm:^3.2.0": version: 3.4.0 resolution: "cli-spinners@npm:3.4.0" checksum: 10c0/91296c32e147d5b973c9d439d1512306499215437b92f0c0d8be44ec850b555acb8795c19c606b2f6747f31d50c4e41fdde7dcef653f18f0ae7cdd58e99a4764 languageName: node linkType: hard "cli-table3@npm:^0.6.5": version: 0.6.5 resolution: "cli-table3@npm:0.6.5" dependencies: "@colors/colors": "npm:1.5.0" string-width: "npm:^4.2.0" dependenciesMeta: "@colors/colors": optional: true checksum: 10c0/d7cc9ed12212ae68241cc7a3133c52b844113b17856e11f4f81308acc3febcea7cc9fd298e70933e294dd642866b29fd5d113c2c098948701d0c35f09455de78 languageName: node linkType: hard "cli-truncate@npm:^6.0.0": version: 6.1.1 resolution: "cli-truncate@npm:6.1.1" dependencies: slice-ansi: "npm:^9.0.0" string-width: "npm:^8.2.0" checksum: 10c0/56760fd0987d1c93711ce603510cce12a97f91d7b4a4f892402a586522aa14633caca86fe410defcfac256f56ea88de757d82d5c874a20eb5861b24d5eebcffb languageName: node linkType: hard "cliui@npm:^9.0.1": version: 9.0.1 resolution: "cliui@npm:9.0.1" dependencies: string-width: "npm:^7.2.0" strip-ansi: "npm:^7.1.0" wrap-ansi: "npm:^9.0.0" checksum: 10c0/13441832e9efe7c7a76bd2b8e683555c478d461a9f249dc5db9b17fe8d4b47fa9277b503914b90bd00e4a151abb6b9b02b2288972ffe2e5e3ca40bcb1c2330d3 languageName: node linkType: hard "code-excerpt@npm:^4.0.0": version: 4.0.0 resolution: "code-excerpt@npm:4.0.0" dependencies: convert-to-spaces: "npm:^2.0.1" checksum: 10c0/b6c5a06e039cecd2ab6a0e10ee0831de8362107d1f298ca3558b5f9004cb8e0260b02dd6c07f57b9a0e346c76864d2873311ee1989809fdeb05bd5fbbadde773 languageName: node linkType: hard "commander@npm:^14.0.0": version: 14.0.3 resolution: "commander@npm:14.0.3" checksum: 10c0/755652564bbf56ff2ff083313912b326450d3f8d8c85f4b71416539c9a05c3c67dbd206821ca72635bf6b160e2afdefcb458e86b317827d5cb333b69ce7f1a24 languageName: node linkType: hard "commander@npm:^15.0.0": version: 15.0.0 resolution: "commander@npm:15.0.0" checksum: 10c0/539229c171914ea1ccd45ee5f10d924289a12a684ea3a7a44147abe54003c35ed6de9ae4ad198d88c29fdf403dca0428451a388234e6dc01b6faa978fb207206 languageName: node linkType: hard "commander@npm:^8.3.0": version: 8.3.0 resolution: "commander@npm:8.3.0" checksum: 10c0/8b043bb8322ea1c39664a1598a95e0495bfe4ca2fad0d84a92d7d1d8d213e2a155b441d2470c8e08de7c4a28cf2bc6e169211c49e1b21d9f7edc6ae4d9356060 languageName: node linkType: hard "content-type@npm:3.0.0": version: 3.0.0 resolution: "content-type@npm:3.0.0" checksum: 10c0/4ecb17b151ef272fe3143d2414b78edeea9c7baa45724e2bbcbfc0dbd4bbc5b68d654733df6df2d9c600016af841a25aa26b0a4d290e366b5120705796072d98 languageName: node linkType: hard "content-type@npm:^1.0.4, content-type@npm:^1.0.5": version: 1.0.5 resolution: "content-type@npm:1.0.5" checksum: 10c0/b76ebed15c000aee4678c3707e0860cb6abd4e680a598c0a26e17f0bfae723ec9cc2802f0ff1bc6e4d80603719010431d2231018373d4dde10f9ccff9dadf5af languageName: node linkType: hard "convert-source-map@npm:^2.0.0": version: 2.0.0 resolution: "convert-source-map@npm:2.0.0" checksum: 10c0/8f2f7a27a1a011cc6cc88cc4da2d7d0cfa5ee0369508baae3d98c260bb3ac520691464e5bbe4ae7cdf09860c1d69ecc6f70c63c6e7c7f7e3f18ec08484dc7d9b languageName: node linkType: hard "convert-to-spaces@npm:^2.0.1": version: 2.0.1 resolution: "convert-to-spaces@npm:2.0.1" checksum: 10c0/d90aa0e3b6a27f9d5265a8d32def3c5c855b3e823a9db1f26d772f8146d6b91020a2fdfd905ce8048a73fad3aaf836fef8188c67602c374405e2ae8396c4ac46 languageName: node linkType: hard "cross-spawn@npm:^7.0.6": version: 7.0.6 resolution: "cross-spawn@npm:7.0.6" dependencies: path-key: "npm:^3.1.0" shebang-command: "npm:^2.0.0" which: "npm:^2.0.1" checksum: 10c0/053ea8b2135caff68a9e81470e845613e374e7309a47731e81639de3eaeb90c3d01af0e0b44d2ab9d50b43467223b88567dfeb3262db942dc063b9976718ffc1 languageName: node linkType: hard "css-select@npm:^5.1.0": version: 5.2.2 resolution: "css-select@npm:5.2.2" dependencies: boolbase: "npm:^1.0.0" css-what: "npm:^6.1.0" domhandler: "npm:^5.0.2" domutils: "npm:^3.0.1" nth-check: "npm:^2.0.1" checksum: 10c0/d79fffa97106007f2802589f3ed17b8c903f1c961c0fc28aa8a051eee0cbad394d8446223862efd4c1b40445a6034f626bb639cf2035b0bfc468544177593c99 languageName: node linkType: hard "css-what@npm:^6.1.0": version: 6.2.2 resolution: "css-what@npm:6.2.2" checksum: 10c0/91e24c26fb977b4ccef30d7007d2668c1c10ac0154cc3f42f7304410e9594fb772aea4f30c832d2993b132ca8d99338050866476210316345ec2e7d47b248a56 languageName: node linkType: hard "debug@npm:^4.0.0, debug@npm:^4.4.0, debug@npm:^4.4.3": version: 4.4.3 resolution: "debug@npm:4.4.3" dependencies: ms: "npm:^2.1.3" peerDependenciesMeta: supports-color: optional: true checksum: 10c0/d79136ec6c83ecbefd0f6a5593da6a9c91ec4d7ddc4b54c883d6e71ec9accb5f67a1a5e96d00a328196b5b5c86d365e98d8a3a70856aaf16b4e7b1985e67f5a6 languageName: node linkType: hard "decode-named-character-reference@npm:^1.0.0": version: 1.3.0 resolution: "decode-named-character-reference@npm:1.3.0" dependencies: character-entities: "npm:^2.0.0" checksum: 10c0/787f4c87f3b82ea342aa7c2d7b1882b6fb9511bb77f72ae44dcaabea0470bacd1e9c6a0080ab886545019fa0cb3a7109573fad6b61a362844c3a0ac52b36e4bb languageName: node linkType: hard "depd@npm:~2.0.0": version: 2.0.0 resolution: "depd@npm:2.0.0" checksum: 10c0/58bd06ec20e19529b06f7ad07ddab60e504d9e0faca4bd23079fac2d279c3594334d736508dc350e06e510aba5e22e4594483b3a6562ce7c17dd797f4cc4ad2c languageName: node linkType: hard "dequal@npm:^2.0.0": version: 2.0.3 resolution: "dequal@npm:2.0.3" checksum: 10c0/f98860cdf58b64991ae10205137c0e97d384c3a4edc7f807603887b7c4b850af1224a33d88012009f150861cbee4fa2d322c4cc04b9313bee312e47f6ecaa888 languageName: node linkType: hard "detect-libc@npm:^2.0.3": version: 2.1.2 resolution: "detect-libc@npm:2.1.2" checksum: 10c0/acc675c29a5649fa1fb6e255f993b8ee829e510b6b56b0910666949c80c364738833417d0edb5f90e4e46be17228b0f2b66a010513984e18b15deeeac49369c4 languageName: node linkType: hard "devlop@npm:^1.0.0, devlop@npm:^1.1.0": version: 1.1.0 resolution: "devlop@npm:1.1.0" dependencies: dequal: "npm:^2.0.0" checksum: 10c0/e0928ab8f94c59417a2b8389c45c55ce0a02d9ac7fd74ef62d01ba48060129e1d594501b77de01f3eeafc7cb00773819b0df74d96251cf20b31c5b3071f45c0e languageName: node linkType: hard "devtools-protocol@npm:0.0.1666840": version: 0.0.1666840 resolution: "devtools-protocol@npm:0.0.1666840" checksum: 10c0/ccc9a31ba2616cb5a90c7eed525ffb489075155afefeec050389ddb84b5b3910aae92b91a5ec41197ed30d851902bc21760d0c2d40702e2b7033303b531bac5e languageName: node linkType: hard "dom-serializer@npm:^2.0.0": version: 2.0.0 resolution: "dom-serializer@npm:2.0.0" dependencies: domelementtype: "npm:^2.3.0" domhandler: "npm:^5.0.2" entities: "npm:^4.2.0" checksum: 10c0/d5ae2b7110ca3746b3643d3ef60ef823f5f078667baf530cec096433f1627ec4b6fa8c072f09d079d7cda915fd2c7bc1b7b935681e9b09e591e1e15f4040b8e2 languageName: node linkType: hard "domelementtype@npm:^2.3.0": version: 2.3.0 resolution: "domelementtype@npm:2.3.0" checksum: 10c0/686f5a9ef0fff078c1412c05db73a0dce096190036f33e400a07e2a4518e9f56b1e324f5c576a0a747ef0e75b5d985c040b0d51945ce780c0dd3c625a18cd8c9 languageName: node linkType: hard "domhandler@npm:^5.0.2, domhandler@npm:^5.0.3": version: 5.0.3 resolution: "domhandler@npm:5.0.3" dependencies: domelementtype: "npm:^2.3.0" checksum: 10c0/bba1e5932b3e196ad6862286d76adc89a0dbf0c773e5ced1eb01f9af930c50093a084eff14b8de5ea60b895c56a04d5de8bbc4930c5543d029091916770b2d2a languageName: node linkType: hard "domutils@npm:^3.0.1, domutils@npm:^3.2.2": version: 3.2.2 resolution: "domutils@npm:3.2.2" dependencies: dom-serializer: "npm:^2.0.0" domelementtype: "npm:^2.3.0" domhandler: "npm:^5.0.3" checksum: 10c0/47938f473b987ea71cd59e59626eb8666d3aa8feba5266e45527f3b636c7883cca7e582d901531961f742c519d7514636b7973353b648762b2e3bedbf235fada languageName: node linkType: hard "ee-first@npm:1.1.1": version: 1.1.1 resolution: "ee-first@npm:1.1.1" checksum: 10c0/b5bb125ee93161bc16bfe6e56c6b04de5ad2aa44234d8f644813cc95d861a6910903132b05093706de2b706599367c4130eb6d170f6b46895686b95f87d017b7 languageName: node linkType: hard "emoji-regex@npm:^10.3.0": version: 10.6.0 resolution: "emoji-regex@npm:10.6.0" checksum: 10c0/1e4aa097bb007301c3b4b1913879ae27327fdc48e93eeefefe3b87e495eb33c5af155300be951b4349ff6ac084f4403dc9eff970acba7c1c572d89396a9a32d7 languageName: node linkType: hard "emoji-regex@npm:^8.0.0": version: 8.0.0 resolution: "emoji-regex@npm:8.0.0" checksum: 10c0/b6053ad39951c4cf338f9092d7bfba448cdfd46fe6a2a034700b149ac9ffbc137e361cbd3c442297f86bed2e5f7576c1b54cc0a6bf8ef5106cc62f496af35010 languageName: node linkType: hard "encodeurl@npm:^2.0.0": version: 2.0.0 resolution: "encodeurl@npm:2.0.0" checksum: 10c0/5d317306acb13e6590e28e27924c754163946a2480de11865c991a3a7eed4315cd3fba378b543ca145829569eefe9b899f3d84bb09870f675ae60bc924b01ceb languageName: node linkType: hard "encoding-sniffer@npm:^0.2.1": version: 0.2.1 resolution: "encoding-sniffer@npm:0.2.1" dependencies: iconv-lite: "npm:^0.6.3" whatwg-encoding: "npm:^3.1.1" checksum: 10c0/d6b591880788f3baf8dd1744636dd189d24a1ec93e6f9817267c60ac3458a5191ca70ab1a186fb67731beff1c3489c6527dfdc4718158ed8460ab2f400dd5e7d languageName: node linkType: hard "entities@npm:^4.2.0, entities@npm:^4.5.0": version: 4.5.0 resolution: "entities@npm:4.5.0" checksum: 10c0/5b039739f7621f5d1ad996715e53d964035f75ad3b9a4d38c6b3804bb226e282ffeae2443624d8fdd9c47d8e926ae9ac009c54671243f0c3294c26af7cc85250 languageName: node linkType: hard "entities@npm:^6.0.0": version: 6.0.1 resolution: "entities@npm:6.0.1" checksum: 10c0/ed836ddac5acb34341094eb495185d527bd70e8632b6c0d59548cbfa23defdbae70b96f9a405c82904efa421230b5b3fd2283752447d737beffd3f3e6ee74414 languageName: node linkType: hard "entities@npm:^7.0.1": version: 7.0.1 resolution: "entities@npm:7.0.1" checksum: 10c0/b4fb9937bb47ecb00aaaceb9db9cdd1cc0b0fb649c0e843d05cf5dbbd2e9d2df8f98721d8b1b286445689c72af7b54a7242fc2d63ef7c9739037a8c73363e7ca languageName: node linkType: hard "entities@npm:^8.0.0": version: 8.0.0 resolution: "entities@npm:8.0.0" checksum: 10c0/938e631664c19451823344a351aeeafd74fae2d5fa51e4d5b6ff635afaefd4bacf0f609989888c04c42733f46ffdac15211608267ebb02488005891a4793e94d languageName: node linkType: hard "env-paths@npm:^2.2.0": version: 2.2.1 resolution: "env-paths@npm:2.2.1" checksum: 10c0/285325677bf00e30845e330eec32894f5105529db97496ee3f598478e50f008c5352a41a30e5e72ec9de8a542b5a570b85699cd63bd2bc646dbcb9f311d83bc4 languageName: node linkType: hard "environment@npm:^1.0.0": version: 1.1.0 resolution: "environment@npm:1.1.0" checksum: 10c0/fb26434b0b581ab397039e51ff3c92b34924a98b2039dcb47e41b7bca577b9dbf134a8eadb364415c74464b682e2d3afe1a4c0eb9873dc44ea814c5d3103331d languageName: node linkType: hard "es-module-lexer@npm:^2.3.2": version: 2.3.2 resolution: "es-module-lexer@npm:2.3.2" checksum: 10c0/5e7389424c43478439f12f9a6aca1750f6f99afa384fc3de329f4a45f152ab156671055008adaafc74960877abf8cc338aeebf6bed8c21297b146fd6eb7a22f8 languageName: node linkType: hard "es-toolkit@npm:^1.45.1": version: 1.51.0 resolution: "es-toolkit@npm:1.51.0" dependenciesMeta: "@trivago/prettier-plugin-sort-imports@4.3.0": unplugged: true prettier-plugin-sort-re-exports@0.0.1: unplugged: true vitepress-plugin-sandpack@1.1.4: unplugged: true checksum: 10c0/ad519228a317a27b11144b582c1168c552143dd58ce4e62be50c185de48c69dea996f6ad6ebc518129ebd58c34da150c1a2134d4a3d7cdc75120c626e57ce7c4 languageName: node linkType: hard "escalade@npm:^3.1.1": version: 3.2.0 resolution: "escalade@npm:3.2.0" checksum: 10c0/ced4dd3a78e15897ed3be74e635110bbf3b08877b0a41be50dcb325ee0e0b5f65fc2d50e9845194d7c4633f327e2e1c6cce00a71b617c5673df0374201d67f65 languageName: node linkType: hard "escape-html@npm:^1.0.3": version: 1.0.3 resolution: "escape-html@npm:1.0.3" checksum: 10c0/524c739d776b36c3d29fa08a22e03e8824e3b2fd57500e5e44ecf3cc4707c34c60f9ca0781c0e33d191f2991161504c295e98f68c78fe7baa6e57081ec6ac0a3 languageName: node linkType: hard "escape-string-regexp@npm:^2.0.0": version: 2.0.0 resolution: "escape-string-regexp@npm:2.0.0" checksum: 10c0/2530479fe8db57eace5e8646c9c2a9c80fa279614986d16dcc6bcaceb63ae77f05a851ba6c43756d816c61d7f4534baf56e3c705e3e0d884818a46808811c507 languageName: node linkType: hard "escape-string-regexp@npm:^5.0.0": version: 5.0.0 resolution: "escape-string-regexp@npm:5.0.0" checksum: 10c0/6366f474c6f37a802800a435232395e04e9885919873e382b157ab7e8f0feb8fed71497f84a6f6a81a49aab41815522f5839112bd38026d203aea0c91622df95 languageName: node linkType: hard "estree-walker@npm:^3.0.3": version: 3.0.3 resolution: "estree-walker@npm:3.0.3" dependencies: "@types/estree": "npm:^1.0.0" checksum: 10c0/c12e3c2b2642d2bcae7d5aa495c60fa2f299160946535763969a1c83fc74518ffa9c2cd3a8b69ac56aea547df6a8aac25f729a342992ef0bbac5f1c73e78995d languageName: node linkType: hard "etag@npm:^1.8.1": version: 1.8.1 resolution: "etag@npm:1.8.1" checksum: 10c0/12be11ef62fb9817314d790089a0a49fae4e1b50594135dcb8076312b7d7e470884b5100d249b28c18581b7fd52f8b485689ffae22a11ed9ec17377a33a08f84 languageName: node linkType: hard "expect-type@npm:^1.4.0": version: 1.4.0 resolution: "expect-type@npm:1.4.0" checksum: 10c0/d40d76b8570695d36587beb3cc28494da2ca3ec8f04e67f5622ed2d372d850e401a9adef19c6835e1a8173903f157c79540b34c7b3fbd7cd8ce726cc903c57b7 languageName: node linkType: hard "exponential-backoff@npm:^3.1.1": version: 3.1.3 resolution: "exponential-backoff@npm:3.1.3" checksum: 10c0/77e3ae682b7b1f4972f563c6dbcd2b0d54ac679e62d5d32f3e5085feba20483cf28bd505543f520e287a56d4d55a28d7874299941faf637e779a1aa5994d1267 languageName: node linkType: hard "extend@npm:^3.0.0": version: 3.0.2 resolution: "extend@npm:3.0.2" checksum: 10c0/73bf6e27406e80aa3e85b0d1c4fd987261e628064e170ca781125c0b635a3dabad5e05adbf07595ea0cf1e6c5396cacb214af933da7cbaf24fe75ff14818e8f9 languageName: node linkType: hard "fast-glob@npm:^3.3.3": version: 3.3.3 resolution: "fast-glob@npm:3.3.3" dependencies: "@nodelib/fs.stat": "npm:^2.0.2" "@nodelib/fs.walk": "npm:^1.2.3" glob-parent: "npm:^5.1.2" merge2: "npm:^1.3.0" micromatch: "npm:^4.0.8" checksum: 10c0/f6aaa141d0d3384cf73cbcdfc52f475ed293f6d5b65bfc5def368b09163a9f7e5ec2b3014d80f733c405f58e470ee0cc451c2937685045cddcdeaa24199c43fe languageName: node linkType: hard "fastq@npm:^1.6.0": version: 1.20.1 resolution: "fastq@npm:1.20.1" dependencies: reusify: "npm:^1.0.4" checksum: 10c0/e5dd725884decb1f11e5c822221d76136f239d0236f176fab80b7b8f9e7619ae57e6b4e5b73defc21e6b9ef99437ee7b545cff8e6c2c337819633712fa9d352e languageName: node linkType: hard "fdir@npm:^6.5.0": version: 6.5.0 resolution: "fdir@npm:6.5.0" peerDependencies: picomatch: ^3 || ^4 peerDependenciesMeta: picomatch: optional: true checksum: 10c0/e345083c4306b3aed6cb8ec551e26c36bab5c511e99ea4576a16750ddc8d3240e63826cc624f5ae17ad4dc82e68a253213b60d556c11bfad064b7607847ed07f languageName: node linkType: hard "figures@npm:^6.1.0": version: 6.1.0 resolution: "figures@npm:6.1.0" dependencies: is-unicode-supported: "npm:^2.0.0" checksum: 10c0/9159df4264d62ef447a3931537de92f5012210cf5135c35c010df50a2169377581378149abfe1eb238bd6acbba1c0d547b1f18e0af6eee49e30363cedaffcfe4 languageName: node linkType: hard "fill-range@npm:^7.1.1": version: 7.1.1 resolution: "fill-range@npm:7.1.1" dependencies: to-regex-range: "npm:^5.0.1" checksum: 10c0/b75b691bbe065472f38824f694c2f7449d7f5004aa950426a2c28f0306c60db9b880c0b0e4ed819997ffb882d1da02cfcfc819bddc94d71627f5269682edf018 languageName: node linkType: hard "finalhandler@npm:^2.1.1": version: 2.1.1 resolution: "finalhandler@npm:2.1.1" dependencies: debug: "npm:^4.4.0" encodeurl: "npm:^2.0.0" escape-html: "npm:^1.0.3" on-finished: "npm:^2.4.1" parseurl: "npm:^1.3.3" statuses: "npm:^2.0.1" checksum: 10c0/6bd664e21b7b2e79efcaace7d1a427169f61cce048fae68eb56290e6934e676b78e55d89f5998c5508871345bc59a61f47002dc505dc7288be68cceac1b701e2 languageName: node linkType: hard "find-up@npm:^5.0.0": version: 5.0.0 resolution: "find-up@npm:5.0.0" dependencies: locate-path: "npm:^6.0.0" path-exists: "npm:^4.0.0" checksum: 10c0/062c5a83a9c02f53cdd6d175a37ecf8f87ea5bbff1fdfb828f04bfa021441bc7583e8ebc0872a4c1baab96221fb8a8a275a19809fb93fbc40bd69ec35634069a languageName: node linkType: hard "foreground-child@npm:^3.1.1": version: 3.3.1 resolution: "foreground-child@npm:3.3.1" dependencies: cross-spawn: "npm:^7.0.6" signal-exit: "npm:^4.0.1" checksum: 10c0/8986e4af2430896e65bc2788d6679067294d6aee9545daefc84923a0a4b399ad9c7a3ea7bd8c0b2b80fdf4a92de4c69df3f628233ff3224260e9c1541a9e9ed3 languageName: node linkType: hard "fresh@npm:^2.0.0": version: 2.0.0 resolution: "fresh@npm:2.0.0" checksum: 10c0/0557548194cb9a809a435bf92bcfbc20c89e8b5eb38861b73ced36750437251e39a111fc3a18b98531be9dd91fe1411e4969f229dc579ec0251ce6c5d4900bbc languageName: node linkType: hard "fsevents@npm:~2.3.3": version: 2.3.3 resolution: "fsevents@npm:2.3.3" dependencies: node-gyp: "npm:latest" checksum: 10c0/a1f0c44595123ed717febbc478aa952e47adfc28e2092be66b8ab1635147254ca6cfe1df792a8997f22716d4cbafc73309899ff7bfac2ac3ad8cf2e4ecc3ec60 conditions: os=darwin languageName: node linkType: hard "fsevents@patch:fsevents@npm%3A~2.3.3#optional!builtin