OAS 3.1.0-rc0 Released!
Pre-release
Pre-release
Changelog
As part of this release, we have decided to not follow SemVer anymore, and as such introduce breaking changes. These changes are documented as part of the release notes.
Additions
- Introduced a new top-level field -
webhooks
. This allows describing out-of-band webhooks that are available as part of the API. - The Info Object has a new
summary
field. - The License Object now has a new
identifier
field for SPDX licenses. - Components Object now has a new entry
pathItems
, to allow for reusablePath Item Object
s to be defined within a valid OpenAPI document.
Extended Functionality
- Updated primitive types to be based on JSON Schema Specification Draft 2019-09. This now includes type
null
. - Lifted the restriction of allowing Request Body only in HTTP methods where the HTTP 1.1 specification RFC7231 has explicitly defined semantics for. While allowed in other methods, it is not recommended.
- Added support to
object
type
forspaceDelimited
andpipeDelimited
style
values. - The Encoding Object now supports
style
,explode
andallowReserved
formultipart/form-data
media type as well. - To enable better
webhooks
support, expressions in theCallback Object
can now also referencePath Item Object
s. - When using the Reference Object,
summary
anddescription
fields can now be overridden. - The Schema Object is now fully compliant with JSON Schema draft 2019-09 (see JSON Schema Core and JSON Schema Validation). See also,
Breaking Changes
- The Discriminator Object can now be extended with Specification Extensions.
- Added support for mutual TLS (
mutualTLS
) as a security scheme. - Used security requirements can now define an array of roles that are required for execution (and not only scopes for OAuth 2.0 security schemes).
Changes
- An OpenAPI Document now requires at least one of
paths
,components
orwebhooks
to exist at the top level. While previous versions requiredpaths
, now a valid OpenAPI Document can describe only webhooks, or even only reusable components. Thus, an OpenAPI Document no longer necessarily describes an API. - Anywhere in the 3.0.0 Specification that had a type of Schema Object | Reference Object has been replaced to be Schema Object only. With the move to full JSON Schema support,
$ref
is inherently part of theSchema Object
and has its own defined behavior. - Extensions prefixed with
x-oas-
are now reserved for the OpenAPI Initiative. format
is now not validated by default.
Breaking changes
- The specification versioning no longer follows SemVer.
- The
nullable
keyword has been removed from theSchema Object
(null
can be used as a type value). exclusiveMaximum
andexclusiveMinimum
cannot acceptboolean
values (following JSON Schema).- Due to the compliance with JSON Schema, there is no longer interaction between
required
andreadOnly
/writeOnly
in relation to requests and responses. format
(whetherbyte
,binary
, orbase64
) is no longer used to describe file payloads. As part of JSON Schema compliance, nowcontentEncoding
andcontentMediaType
can be used for such specification.
Clarifications
- Reworded the definition of OpenAPI Document to reflect that a document no longer must describe paths, but can describe either paths, webhooks, components or any combination of them.
- Dropped the term RESTful APIs in favor of HTTP APIs
- Resolution of relative references has been redefined and clarified. Note there's a difference in resolution between Schema Object References and all others.
- Modification of examples to improve them and provide context for new fields/objects.