Skip to main content
Tag

OAS

OpenAPI Specification 3.1.0 Released

By Announcement, Blog

OpenAPI developer community and JSON Schema community work together to build upgrade that supports 100% compatibility with the latest draft of JSON Schema

SAN FRANCISCO – February 18, 2021 – The OpenAPI Initiative, the consortium of forward-looking industry experts focused on creating, evolving and promoting the OpenAPI Specification (OAS), a vendor-neutral, open description format for HTTP (including RESTful) APIs, announced today that the OpenAPI Specification 3.1.0 has been released. This new version now supports 100% compatibility with the latest draft (2020-12) of JSON Schema.

Along with this release, the OpenAPI Initiative has sponsored the creation of new documentation to make it easier to understand the structure of the specification and its benefits. It is available here: https://oai.github.io/Documentation/ 

The OpenAPI Specification is a broadly adopted industry standard for describing modern APIs. It defines a standard, programming language-agnostic interface description for HTTP APIs which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. 

The OpenAPI Specification (OAS) is used by organizations worldwide including Atlassian, Bloomberg, eBay, Google, IBM, Microsoft, Oracle, Postman, SAP, SmartBear, Vonage, and many more.

“The benefits of using the OpenAPI Specification are broadly applicable, ranging from API lifecycle management, to documentation, to security, to microservices development and much, much more,” said Marsh Gardiner, Product Manager, Google, and Technical Steering Committee, OpenAPI Initiative. “Great care was taken in evolving to version 3.1.0 to ensure it is an incremental upgrade for existing users, while also making it an excellent candidate for immediate evaluation and adoption in corporate environments. We extend our heartfelt gratitude to the diverse group of contributors for all their exceptional skills and effort on our latest achievement.”

“The mismatch between OpenAPI JSON Schema-like structures and JSON Schema itself has long been a problem for users and implementers. Full alignment of OpenAPI 3.1.0 with JSON Schema draft 2020-12 will not only save users much pain, but also ushers in a new standardised approach to schema extensions,” said Ben Hutton, JSON Schema project lead. “We’ve spent the last few years (and release) making sure we can clearly hear and understand issues the community faces. With our time limited volunteer based effort, not only have we fixed many pain points and added new features, but JSON Schema vocabularies allows for standards to be defined which cater for use cases beyond validation, such as the generation of code, UI, and documentation.

On Day One of JSON Schema draft 2020-12 being released, two implementations were ready. It’s humbling to work with such an experienced and skilled team.”

While JSON Schema is still technically a “draft” specification, draft 2020-12 sets a new stable foundation on which 3rd parties can build standardised extensions. The JSON Schema team do not foresee any major changes to the approach of the extension system, like dialects and vocabularies. However, the utility may be improved as feedback is received.

JSON Schema website: https://json-schema.org 

JSON Schema Open Collective: https://opencollective.com/json-schema 

JSON Schema Twitter: https://twitter.com/jsonschema

Major Changes in OpenAPI Specification 3.1.0

  • JSON Schema vocabularies alignment
  • New top-level element for describing Webhooks that are registered and managed out of band
  • Support for identifying API licenses using the standard SPDX identifier
  • PathItems object is now optional to make it simpler to create reusable libraries of components. Reusable PathItems can be described in the components object. There is also support for describing APIs secured using client certificates.

Full OpenAPI Specification 3.1.0 release notes are available here: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0

A Note on Semantic Versioning

The OpenAPI Initiative had adopted semantic versioning to communicate the significance of changes in software upgrades. Semantic versioning is a popular numbering methodology where minor version updates indicate changes to software are backward compatible, whereas major updates are not. Technically, using semantic versioning with the new full alignment with JSON Schema would require this change to be denoted as 4.0.0. However, this update to OpenAPI important improvements, specifically the alignment with JSON Schema, but to force it into a major release numbering would have created a mismatch of expectations.

Special Thanks

A special callout to Henry Andrews, Phil Sturgeon, and Ben Hutton for all their work, support and patient explanations they have provided to better align JSON Schema and the OpenAPI Specification. Many thanks to Lorna Mitchell for driving the Webhooks effort, using our new proposal process. And thanks to the many, many open source developers involved worldwide.

OpenAPI Resources

To learn more about participate in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

●   Become a Member

●   OpenAPI Specification Twitter

●   OpenAPI Specification GitHub – Get started immediately!

●   Share your OpenAPI Spec v3 Implementations

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Migrating from OpenAPI 3.0 to 3.1.0

By Blog

This post is authored by Phil Sturgeon, product manager, Stoplight, and Chairperson, Protect Earth. If you’d like to donate to Phil’s charity of choice, please see Protect Earth which is reforesting the U.K. one field at a time.

OpenAPI v3.1 brings a lot of great new functionality and improvements, and at some point in the near future you might find yourself wanting to upgrade. If you’re ready to give it a try, let’s take a look at the changes you may, or may not, need to make in order to get onto OpenAPI v3.1.

First things first, let’s change that version number! Open up your OpenAPI JSON or YAML file, and look for this line:

openapi: 3.0.3

Change that to.

openapi: 3.1.0

If instead of `openapi: 3.0.3` you see `swagger: 2.0` then see if swagger2openapi can help you upgrade to v3.0 before continuing.

In a perfect world this would be all you need to do, but despite the minor version number, v3.1 does have some small breaking changes. This decision was not made lightly. Thankfully the scope of the breaking changes is incredibly small, limited to the Schema Object, and achieves a much greater goal: full compatibility with modern JSON Schema.

OpenAPI Schema is now valid JSON Schema

Everything inside the `schema` keyword in OpenAPI is defined by the Schema Object. This has always been loosely based on JSON Schema, and referred to as a “subset superset” because it adds some things, and removes some other things from JSON Schema. This has caused confusion for some folks in the OpenAPI community. To resolve the subset superset problem, contributors from both communities came together, and got these two specifications aligned. 

OpenAPI v3.0 was based on JSON Schema Draft 05, and JSON Schema has gone through a few drafts since then: Draft 06, Draft 07, and Draft 2019-09. Now thanks to feedback gathered from users and tooling maintainers during the v3.1.0 release candidates, one more small draft was released: Draft 2020-12. This should be the last one for a while and no major changes are planned by the JSON Schema crew, so if all goes well a final release is on the horizon, to avoid any further discrepancies. 

Supporting modern JSON Schema brings lots of handy new functionality, including being able to use items arrays for tuples, or the if/then/else keywords as an alternative to awkward nested allOf > oneOf chains some folks were using for more dynamic payloads. We don’t need to learn every new thing JSON Schema can do right now, but if we’re going to upgrade we will need to know what to change in our OpenAPI documents.

Schema Object Changes

Swap nullable for type arrays

In line with JSON Schema, the `type` keyword can now define multiple types for a schema with an array. This is useful new functionality, but has also made nullable redundant. In order to achieve the goal of letting JSON Schema tools understand OpenAPI, it was decided to remove nullable entirely instead of deprecate it. 

# OpenAPI v3.0
type: string
nullable: true

# OpenAPI v3.1
type:
- "string"
- "null" 

This follows the keyword independence concept, where keywords should only add constraints, but adding one more keyword should not remove a constraint. Find and replace should solve this one rather quickly.

Tweak exclusiveMinimum and exclusiveMaximum

These two keywords used to take a boolean value, which would modify the meaning of the `minimum` and `maximum` properties. In OpenAPI v3.1 they are distinct values.

# OpenAPI v3.0
minimum: 7
exclusiveMinimum: true
# OpenAPI v3.1
exclusiveMinimum: 7

Again this one can be solved with some find and replace, and I’d wager many of you don’t even use this keyword for anything.

Use examples not example

OpenAPI has a lot of places that can have an example, or multiple examples. OpenAPI v3.0 can have `example` or `examples` at the Media Type level (requests, responses, callbacks, and webooks) but it can also have a very different type of `example` inside the Schema Object. This schema object singular example was an OpenAPI-specific keyword which is no longer necessary now as JSON Schema has `examples`.

This might need an visualisation, which I will defer to Lorna Mitchell because she made some excellent slides for her talk at APIDays Paris.

# OpenAPI v3.0
type: string
example: fedora
# OpenAPI v3.1
type: string
examples: 
 - fedora

Basically switching any `example` inside a `schema` to `examples` and adding a hyphen at the start (which is a YAML array).

This is more typing if you’re writing YAML entirely by hand instead of using a visual editor, but it’s also a feature: adding multiple examples is now a lot easier. In the past to get multiple examples for a property or schema you would have to switch the type of example being used, from a property example to a media type example, which felt like overkill. Now you can do this:

type: string
examples: 
 - fedora
 - ubuntu

Describing File Upload Payloads 

In OpenAPI v3.0, describing file uploads was signalled with a type: string and the format set to byte, binary, or base64. JSON Schema helps make this far more clear with its contentEncoding and contentMediaType keywords, which are designed for exactly this sort of use.

Uploading a binary file in a POST request? No need to even use a schema now.

# OpenAPI v3.0
requestBody:
  content:
    application/octet-stream:
      schema:
        type: string
        format: binary

# OpenAPI v3.1

# OpenAPI v3.1
requestBody:
  content:
    application/octet-stream: {}

Uploading an image with base64 encoding?

# OpenAPI v3.0
requestBody:
  content:
    image/png:
      schema:
        type: string
        format: base64
# OpenAPI v3.1
requestBody:
  content:
    image/png:
      schema:
        type: string
        contentEncoding: base64

Multipart file uploads with a binary file?

# OpenAPI v3.0
requestBody:
  content:
    multipart/form-data:
  	schema:
       type: object
       properties:
        orderId:
          type: integer
        fileName:
          type: string
          format: binary
# OpenAPI v3.1
requestBody:
  content:
    multipart/form-data:
  	schema:
       type: object
       properties:
        orderId:
          type: integer
        fileName:
          type: string
          contentMediaType: application/octet-stream

This keyword supports all encodings defined in RFC4648, including “base64” and “base64url”, as well as “quoted-printable” from RFC2045.

Declaring $schema Dialects to protect against change

That’s it for things you’ll need to change, and there’s lots of other functionality I could talk about, but one thing which will help avoid change in the future is the ability to define a $schema in your schemas. 

$schema now allowed

The $schema keyword is optional but a useful way to define exactly what JSON Schema dialect a model is written in, which could be different drafts or even custom dialects. Tools which support multiple dialects can process the files slightly differently, meaning you don’t always need to make changes to all your models when upgrading OpenAPI versions in the future.

OpenAPI is entirely compatible with JSON Schema because it is now a JSON Schema dialect, so by default any schema is using `$schema. “https://spec.openapis.org/oas/3.1/dialect/base”` dialect. If you split your schemas into other JSON/YAML files and use $ref to point to them, they could contain a different $schema and override this default.

{
   $schema: "http://json-schema.org/draft-07/schema#",
}

This makes things a lot easier for tooling maintainers, because they no longer need to try and guess what draft a schema is by looking at where it is referenced from. In the past this created impossible situations where a single schema was referenced by OAS2 and OAS3 at the same time, and might have worked for a while, until a OAS3 specific keyword was added, now everything is broken for the OAS2 usage. 

Now all models can declare their own dialect and if an OpenAPI document references a dialect that the tools do not understand how to parse, it will be immediately clear, instead of breaking after several months of usage and confusing everyone. 

From APIDays Paris: OpenAPI 3.1 Coming Soon

By Blog

Originally posted in the LORNAJANE Blog – Thank you, Lorna!

What’s New in OpenAPI 3.1

With OpenAPI 3.1 coming “soon”, I gave a talk at APIDays Paris about what to expect. But I’m a great fan of the written word as reference so here’s a written recap of what’s in the next OpenAPI release.

Top features:
– Compatible with JSON Schema 2020-12
– Webhook support
– Many other minor improvements

Version Numbering

As of OpenAPI 3.1, the OpenAPI project doesn’t follow semantic versioning. That sounds like a totally irresponsible decision but it actually makes some sense for a standard where every API description clearly states the version of OpenAPI it relates to. Also, they don’t let me make the rules, sadly! It’s not a major release, but some things had to be undone and redone to accommodate JSON Schema.

JSON Schema 2020-12

This is really big news, so much of OpenAPI is used alongside JSON Schema and the 3.0 release was quite a long time ago and didn’t quite accommodate everything that makes sense today in JSON Schema. This post won’t cover what’s new in JSON Schema itself but I’ll try to round up the main points from the perspective of OpenAPI users.

First of all: types can now be arrays of types, so something could be of type [string,number]. The available types also include null, so more common will be [string, ‘null’]. This does impact on existing OpenAPI documents as from 3.1, the nullable keyword is removed – use the array of types and one of the types is null.

parameters:
  - name: friendly-label
    in: query
    schema:
      type:
        - string
        - 'null'

OpenAPI 3.1 is getting support for the examples keyword within a schema, allowing an array of examples. Often the array only contains one element though. The original singular example keyword is still valid, but examples is recommended and if both are present then examples is preferred. Be aware that this array of values is in contrast with the other use of examples in OpenAPI, in a MediaType content object, where the examples field is a map with string keys. Confused? So are we. There is a post all about OpenAPI examples from Phil that explains it all!

A couple of other things are coming in from JSON Schema into the OpenAPI schemas. First of all: arbitrary keys are allowed in a schema; OpenAPI has relaxed its constraints on which fields can appear where to accommodate JSON Schema format objects. Also it’s possible to $ref to an object, then put keys alongside it which are considered in addition to what is defined in the component.

content:
  'application/json':
    schema:
      $ref: '#/components/schemas/style'
      required:
        - hue

None of these changes are huge, but having the ability to use JSON Schema within OpenAPI is brilliant for anyone wanting to use the two together so to have this commitment to supporting the ever-improving JSON Schema is excellent news.

Webhooks

I’m totally biased because I proposed this feature. I couldn’t believe that OpenAPI didn’t already support this common use case and it took time to realise that it wasn’t that I didn’t understand how to do something – that thing really was outside what OpenAPI 3.0 expected APIs to describe.

OpenAPI 3.0 does have support for callbacks so if the user should make an API call, supply a URL, and stand by for incoming HTTP requests to that URL as a result, that’s already supported. This is ideal when an endpoint asynchronously returns data, or for some situations where an API call “subscribes” to an event and gives a URL to send things to.

OpenAPI 3.1 goes a step further and allows webhooks which are incoming HTTP requests that are in response to some external event or stimulus. A great example would be if you’ve ever linked anything to a GitHub push event, or an incoming order/payment/message (and I’ve been working for a communications company for a few years, so you can immediately understand how I got entangled in this). The webhooks are described a LOT like the existing callbacks are, and indeed both are much like the existing request descriptions, so I hope this change will be easily adopted by everyone who has a two-way API like this.

The new webhooks keyword is a top-level element, alongside paths. There are also changes to the required fields: OpenAPI 3.0 required openapi and info and paths but in OpenAPI 3.1 only openapi and info are always required, but the document must also contain at least one of paths or webhooks or components. This is brilliant because it allows API descriptions to contain only outgoing API calls, only incoming webhooks, only components that might be referred to by other documents, or any combination or all of these – and still be valid in its own right.

Anyway, back to the webhooks.

webhooks:
  inbound-sms:
    post:
      operationId: inbound-sms
      requestBody:
        content:
          application/json: ...
      responses: ...

Within the webhooks section, each incoming “thing” has a key (such as inbound-sms in the example above) and then it goes on just … looking like a pathItem, because that is all it is. You don’t need to specify the URL path that the webhook will come in on (often the user can nominate that anyway), just explain what will arrive and you are done. Oh and related to this: pathItem is now allowed in the components section and you can $ref to a pathItem from either a path or a callback or a webhook.

Fancy a sneak preview of what the webhooks will look like when the tools get support for it? Redoc already has preview support if you use x-webhooks in your 3.0 OpenAPI documents! I mean, it just looks like really competent API documentation but that’s what we need here 🙂


A note about webhooks and callbacks. Quite a few endpoints could be considered as either a webhook or a callback, and I have already started getting questions about which to use. It probably doesn’t matter but if there is no preceeding API call that the callback is a response to, then it’s definitely a webhook. Where there is some previous API call with a URL, then it’s probably up to you how you want it to work. For example at Vonage the configuration for where to send events for an incoming Message is at the application level, do you do that with the Application API – but I’d rather have the API description with the incoming Message webhook detail shown next to the send Message API call, in the same document, tagged and grouped together in the Message API description. The webhooks keyword gives you the flexbility to approach this as you will.

Small But Perfectly-Formed Upgrades

There are so many small things that have been added in OpenAPI 3.1 but I’m picking my favourites to include! As with every *.1 release, there are things that seemed like a good idea for the *.0 release that can now be tidied up a little now we’ve all tried them out in anger, it’s a good thin.

I’ll start with the one I want to implement immediately (or as soon as the tools allow): $ref can now have summary and description as siblings, and they override any existing fields on the referred-to component.

paths:
  /items:
    post:
      parameters:
        - $ref: '#/components/parameters/item'
          description: The specific item in question

There are a few minor things in the info section as well:

  • Inside info, you can now have summary alongside the description field. Both are optional – title is still required.
  • In the license object you can use an SPDX code in the new identifier field instead of a url alongside the required name field if you prefer

Finally, paths are no longer required to have responses field for every endpoint. This is useful when an OpenAPI document is under construction because it means that it will validate even when you’re still only sketching out the endpoints that the API definition will include.

Further Reading

I’ll share links to my talk when the recording is published (the slides are on notist but keep up with the current status of the OpenAPI 3.1 release and read the (much better) changelogs on the project itself for more information https://github.com/OAI/OpenAPI-Specification/releases.