Creating custom OpenAPI specifications
This template can be used to create a new swagger specification JSON
file.
Field Name | Type | Specification |
---|---|---|
openapi | string | REQUIRED. This string must be the semantic version number of
the OpenAPI specification version that the OpenAPI document uses. The
openapi field should be used by tooling
specifications and clients to interpret the OpenAPI document. This is
not related to the API info.version string. |
info | info Object | REQUIRED Provides metadata about the API. The metadata may be used by the tooling as required. |
servers | [Server Object] | An Array of Server Objects, which provides 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 with a url value of /. |
paths | Paths Object | REQUIRED. The available paths and operations for the API. |
components | Components Object | An element to hold various schemas for the specification. |
security | [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 Objects] | A list of tags used by the specifications 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 must be declared. The tags that are not declared may be organized randomly or based on the toll's logic. Each tag name in the list must be unique. |
externalDocs | External Documentation Object | Additional external documentation. |