[REQ] Support for OpenAPI Spec 3.1

[westn]

Is your feature request related to a problem? Please describe.

Support for OpenAPI Spec 3.1, released last month: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0

Describe the solution you'd like

Add support for OpenAPI Spec 3.1

Additional context

Couldn't see any other mention of this besides a short mention in #15
Another note on https://www.openapis.org/blog/2020/06/18/openapi-3-1-0-rc0-its-here which mention that the specification-change is bigger than it sounds and might break some tooling.

[spacether]

We use swagger-parser to parse openapi specs. That project must implement v 3.1 spec parsing before we can implement it in the generators.

[darkbasic]

https://github.com/swagger-api/swagger-parser/commits/oas3.1

[cgfarmer4]

Any updates to share on potentially updating the generators to OAS 3.1?

[gunsluo]

Any updates to share on potentially updating the generators to OAS 3.1?

swagger-api/swagger-parser#1535, there has been no update for half a year.

[cyangle]

OAS 3.1 support has been added to swagger-parser in swagger-api/swagger-parser#1730

[denisgolubovic]

What release do you aim for this to be implemented in the generator? 6.1.0?

[kiwisincebirth]

swagger-parser 2.1 has been released with OAS 3.1 support
https://github.com/swagger-api/swagger-parser/releases/tag/v2.1.0

[RickKukiela]

This is a big oof on my part. I just spent a ton of time setting up an API spec for a client and used 3.1.0 and now that its all approved I need to actually program the API server and need to generate the base files from the spec. Now I find out that not only does this package not support 3.1.0 currently but I cannot seem to find any code generator that does :( big yikes! I have to figure out what my options are at this point as my spec currently makes heavy use of the type as an array not a string and I also use oneOf with "null" or a $ref throughout the whole thing which makes it a major problem to downgrade to 3.0.3 at this point.

I see that as of 27 days ago at the time of me writing this, the 3.1 spec was added to swagger-api/swagger-parser#1535 - Does anyone have any idea when there will be a beta / snapshot release that will support 3.1.0 as if its going to be soon(tm), I might keep just waiting for that as an option before nuking my 3.1.0 setup....

[slPerryRhodan]

We are also waiting for this feature, to generate classes from components if there is no API (e. g. publish Kafka Event Objects as Open Api Spec). I hope there will be soon a new release for that.

[tobq]

Any updates on 3.1 support?

[Stokestack]

This is a huge impediment. I too have an API that relies on 3.1 features. It seems to be taking the toolchain a very long time to support it.

[spacether]

This is a big oof on my part. I just spent a ton of time setting up an API spec for a client and used 3.1.0 and now that its all approved I need to actually program the API server and need to generate the base files from the spec. Now I find out that not only does this package not support 3.1.0 currently but I cannot seem to find any code generator that does :( big yikes! I have to figure out what my options are at this point as my spec currently makes heavy use of the type as an array not a string and I also use oneOf with "null" or a $ref throughout the whole thing which makes it a major problem to downgrade to 3.0.3 at this point.

I see that as of 27 days ago at the time of me writing this, the 3.1 spec was added to swagger-api/swagger-parser#1535 - Does anyone have any idea when there will be a beta / snapshot release that will support 3.1.0 as if its going to be soon(tm), I might keep just waiting for that as an option before nuking my 3.1.0 setup....

Type null works with 3.0.3 specs and our tool
Type arrays can be converted to oneOf with each type in a different schema.

[philsturgeon]

Hello! As the maintainer of openapi.tools, and as somebody works with Linux Foundation helping out in OpenAPI-land, I'm reaching out to tooling vendors to track the progress towards supporting OpenAPI v3.1, to see what roadblocks there are beyond folks just generally being busy at this ridiculous time.

OpenAPI v3.1 has a bunch of great little changes, solving problems like the JSON Schema <!=> OpenAPI Schema Object divergence. It also fixes some other inconsistencies and duplicate ways of doing things. It's the best version and everyone should be using it, but we need tooling to catch up. Just in case folks didn't notice, or don't have resources to simplify the process, I'm here to give a friendly prod and send over some handy links.

Here are a few articles showing off the differences between OpenAPI v3.0 and v3.1.

• https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0
• https://www.apimatic.io/blog/2021/09/migrating-to-and-from-openapi-3-1/
• https://nordicapis.com/whats-new-in-openapi-3-1-0/

Here are some example files which can make for handy pass/fail test cases:

https://github.com/Mermade/openapi3-examples/tree/master/3.1

If you're looking for the JSON Schema that defines a valid OpenAPI document, that'll be right over here:

https://github.com/OAI/OpenAPI-Specification/tree/main/schemas/v3.1

No rush, but when you're starting work on it, please update this issue so I can update openapi.tools to reflect that, and folks will have a way to subscribe for updates.

LMK if you have any questions!

[marcelstoer]

Apart from the actual lack of 3.1 support the biggest issue I have is that this project does not seem to be open about it.

The README doesn't mention it. https://openapi-generator.tech/ prominently claims

from OpenAPI 2.0/3.x documents

which led me to believe that 3.1 be fully supported.

[RickKukiela]

Probably should say 3.0.x...

[karenetheridge]

It would be helpful to see an itemized list of what is still needed to achieve v3.1 support, so that members of the community can help out. Has anyone identified those tasks?

[spacether]

It would be helpful to see an itemized list of what is still needed to achieve v3.1 support, so that members of the community can help out. Has anyone identified those tasks?

I am putting together that list now and we will publish a project very soon. This is something that we all want to add to openapi-generator. It is ~30 feature additions to store the new openapi/json schema data in our java classes. Then that data needs to be used by the generators to generate code that imposes the new json schema validation + adds new openapi features.

[spacether]

We have a project to track adding 3.1.0 support here:
https://github.com/orgs/OpenAPITools/projects/4/views/1 and welcome any PRs adding these features

Generators that will have 3.1.0 support prioritized:
#13073

Tag for 3.1.0 issues/PRs:
https://github.com/OpenAPITools/openapi-generator/issues?q=is%3Aissue+is%3Aopen+label%3A%22Feature%3A+OAS+3.1.0+spec+support%22

[wing328]

The best way to get updates regarding OpenAPI 3.1 support (beta) is via the Label in the pull request tab: https://github.com/OpenAPITools/openapi-generator/pulls?q=+is%3Apr+label%3A%22Feature%3A+OAS+3.1.0+spec+support%22+

[spacether]

openapi 3.1.0 support added for the java generator in openapi-json-schema-generator

Heads up, I just released v4.2.1 which includes the stable java sdk generator

• It includes thorough endpoint code samples for schema validation an endpoint invocation
  • Pet.addPet endpoint
  • Money schema
• Sealed classes are used for validated schema payloads/request bodies/responses/response bodies
• Code is re-used rather than generated multiple times: If an endpoint has multiple tags, the endpoint method is defined once as a default method in an interface, and that interface is implemented in each tag's api class

[jahlbornG]

@wing328 you mentioned that beta 3.1.0 support is available, but i can't see any information about enabling this support? can you please provide more details?

[david0]

As complete OpenAPI 3.1 support doesn't seem to come soon, I would like to understand what the current state is.

Wouldn't it make sense to document somewhere what experimental means and which features should working correctly?

[wing328]

@jahlbornG it's automatic. if your spec is documented as 3.1.0, it will enable the beta support. v7.7.0 was released last week. please give it a try as it includes more fixes for v3.1.0 spec

[david0]

The enabling is not the question, my question is what to expect? What does beta mean? Should I expect all features to be there and just not as solid as 3.0?

[jahlbornG]

@jahlbornG it's automatic. if your spec is documented as 3.1.0, it will enable the beta support. v7.7.0 was released last week. please give it a try as it includes more fixes for v3.1.0 spec

@wing328 i am using the generator maven plugin to convert a swagger (2.0) document to an openapi spec document. it seems to generate 3.0.1 by default, and i'd love to get it to generate 3.1.0.

[dankgen-tobias]

Is there a roadmap for the full support for 3.1? There is a project https://github.com/orgs/OpenAPITools/projects/4/views/1 that tackles this but there haven't been any changes since january

[trohovsky-mhp]

It would be great if openapi-generator tackled the issue that properties in model classes are generated with Object type instead of String, Integer, etc. #15203

[Haarolean]

@wing328 what's the process of reporting issues encountered while building 3.1 specs? Should I raise a separate issue or sth else?

[wing328]

Should I raise a separate issue

yes please

[bgalek]

Check out this poll: springdoc/springdoc-openapi#2790
I hope 3.1 will be default there, so this feature will be much appreciated ;)

[juliojgd]

Hi @bgalek we haven't found any relevant (complete) support nor (REAL) market adoption of OpenAPI 3.1 (I guess due is a wrong minor version, there are huge breaking changes and it should be a major version instead (among other potential reasons))

So what would be the point to move "official" support to OpenAPI 3.1? Wouldn't it be better to wait for a proper and fixed major version (maybe OpenAPI 4.x)? And keep for the time being the "official" support to OpenAPI 3.0.x

[bgalek]

I've asked a few communities, and people do tend to miss some features in 3.0 (that were introduced to 3.1) like the major one I've described here: springdoc/springdoc-openapi#2765 (comment)

After openapi@4 is published, tools will need to adjust and release new versions. That will take time, and it doesn't mean that 3.1 should not be supported, either.

So, supporting 3.1 and then supporting upcoming 4 are separate tasks ;)

[juliojgd]

Supporting 3.1 I think will a be waste of resources that should be focused in any pending improvements in 3.0 support in all the related tools (OpenAPI generator, springdoc, etc.) and to speed up 4.0 support and adoption when it was released in the short future.

I think that concentrating the effort will be more positive than to disperse it in versions that were wrong from the inception (3.1). To disperse the effort could lead to a less-than-optimal support in valuable versions that deserve the resource assignation.

[Stokestack]

Version 3.1 addresses several baffling defects in version 3.0 that cripple OAS for its intended purpose: documenting APIs. It has been the current version for years now.

One of the most significant fixes in 3.1 is the ability to provide a description alongside any use of a reference (model). This is critical in documenting an API, yet is inexplicably prohibited pre-3.1.

For example: I have a model that represents an integer-based setting on a piece of equipment. There will be dozens or more such settings in a complex API, all of them meaning something different. In every case, I need to describe what one particular integer-based setting is used for, as opposed to some other integer-based setting. Maybe I have one called "Volume" and another one called "Offset" and another called "Tap count." Every one of those is an Integer_setting. How can you document an API without describing each use of its structures?

One can think of endless examples. What about an API that had something to do with surveying or farming, where you needed to work with rectangular land parcels. You might have a model called Rect, referred-to all over the place. What does this Rect mean as opposed to that one? You need to be able to attach a description to each appearance of Rect in the API.

Versions before 3.1 are crippled by this and other design problems. What problems are people calling out in 3.1?

To continue to let tools languish, unusable, for many purposes until a nebulous version 4 appears... and for several more years after that until tools actually support it... seems absurd. You might as well just call OpenAPI a wrap and move on to something else.

[darrelmiller]

There is definitely support for OpenAPI 3.1 in tools, and we are starting to see more 3.1 descriptions in the wild. You can see a list here https://openapi.tools/ of tools that declare they support 3.1. It does take a long time for new versions of specifications to take hold. We saw this in the 2.0 -> 3.0 transition.

Adding 3.1 support for code generators is harder than it is for most tooling because 3.1 opened the doors to a range of different capabilities in JSON Schema 2020-12.

@juliojgd It is certainly debatable as to whether 3.1 should have been 4.0. And certainly to some implementors it feels that way. However, to authors of API Descriptions the changes are 98% additive and not breaking. The decision was hotly debated and it came down to a vote. So, be assured that if you think it should have been 4.0, there are some members of the OpenAPI technical steering committee that agree with you.

But here we are with a 3.1 that is easy for some to support and hard for others. But it is an important step to make, and one that needed to be made. For those saying you should wait for 4.0. I wouldn't recommend that. 4.0 will be a major update and as we have explored the features we want to bring, we have identified that many of the improvements would not be breaking. So, rather than make people wait, for those enhancements, we will be continuing the 3.x line while working on the 4.0 release. There will be a 3.2 release "fairly soon" that will add some simple to add features that should be easy to support. However, we currently are planning a 3.3. release to follow to backport some of the ideas we came up with for moonwalk (4.0).

While this may seem like a lot of work to do for a group that hasn't released a new version in 3 years, we have recently grown the technical steering committee, and there is lots of new life in the group.

@Stokestack I'm glad you like the ability to add description and summary alongside $refs. This previous constraint wasn't a decision made the OpenAPI group. It was a constraint of earlier versions of JSON Schemas because the semantics of merging keywords was not clearly defined. By adopting JSON Schema 2020-12, were able to leverage this work and start bringing peer keywords. We only started with "description" and "summary" because we knew they were safe. If there are other keywords that you believe would be valuable to sit alongside a $ref, let us know by creating an issue in the OpenAPI specification repo.

[Stokestack]

@darrelmiller Thanks for that response. I don't understand how JSON Schema precluded anything, but I haven't studied it. But I didn't think OAS 3 was JSON-Schema-compliant anyway, so I'm perplexed as to why it would be constrained by failings of that standard.

I will keep your suggestion in mind about filing issues on other keywords.

[spacether]

In my opinion some reasons why we don't have more 3.1 tooling here is because

1. users ask for it but few are willing to help us build it (here and another project)
2. users who did build it here (me) had their work deleted from this repo

I was a python team and core team contributor to this repo until they required that I remove my generator from this project. The python generator that I built strove to more fully conform to 3.0.3 and 3.1.0 requirements including running json schema unit tests. If you check my PRs here I added a ton of json schema data to our Java layer and implemented the features in Python. With my code not being wanted here, I hosted it in a new project https://github.com/openapi-json-schema-tools/openapi-json-schema-generator where I saw some adoption but not many contributors over two years. For those reasons I have stopped building my project.

[wing328]

@spacether work can be found in https://github.com/openapitools/openapi-json-schema-generator and he decided to host it elsewhere instead. His approach unfortunately didn't gain attraction and many Python users we contacted switched to something else instead, and therefore we refactored the Python client generator (using pydantic) and have gained many positive feedback and enhancements since the beta release.

As said before, the best way to get updates regarding OpenAPI 3.1 support (beta) is via the Label in the pull request tab: https://github.com/OpenAPITools/openapi-generator/pulls?q=+is%3Apr+label%3A%22Feature%3A+OAS+3.1.0+spec+support%22+, and raise a new issue if needed

For general feedback on OpenAPI specification, please open an issue in the official repo as this project is not affiliated with OpenAPI Initiative (OAI).