- New explicit versioning schema
- Recommend
swagger.json
/swagger.yaml
are now calledopenapi.json
/openapi.yaml
- Switch from Github Flavoured Markdown syntax to CommonMark syntax
- New top-level construct
Components
holds a set of objects to be reused throught the rest of the API. This allows us to define re-used things in one place and reference them, instead of repeating them. Will be especially useful for error responses, pagination parameters, etc - New
info.servers
construct replacesbasePath
. This may allow us to combine all of our separate Open API specs into one, mega spec. - Ability to specify a path parameter at the top level (i.e. no need to duplicate the definition of
{policy_uuid}
for theGET
,PATCH
,PUT
andDELETE
endpoints) - Moving of request BODY parameters into their own part of the path definition
- Support for different request BODY definitions based on the Content-Type of the request (e.g. we could make one API support both JSON and YAML)
- Support for different responses based on Content-Type
- Now able to send paramters to the API in cookies
- Now able to mark endpoints/parameters as deprecated
- Now able to mark querystring parameters as allowed to have empty values
- Can specify that multiple received copies of a parameter should be treated a a list or exploded into muliple parameters
- Parameters can have examples
- Various other parameter changes to allow more detailed specification of how they are serialised
- File uploads can now describe the endcoding they require (
binary
/base64
) - Multi-part form uploads must now have explicitly defined input parameters
- Response codes must be strings (e.g.
'200'
not200
) - Response codes can be defined for ranges (e.g.
1XX
,2XX
,3XX
,4XX
or5XX
) - Response specifications can now specify static links, which are urls with templated parameters based on the response. This means that we don't have to include dynamic
_links
within the response body anymore, reducing the payload size and preventing duplication on fetch endpoints. - Capability to send
null
as a parameter value - Schema composition, inheritance and polymorphism. This will allow us to make generic endpoints which validate the request based on parameters in the request (e.g. make Connexion validate that the
data
part of a request is valid against theschema
uuid defined in the request). Thediscriminator
in the request allows valiation against different schemas. - Support for bearer tokens as an API security format (i.e. JWT)
Links: