Hi @julealgon,
Thanks for using kiota and for reaching out.
Kiota relies on OpenAPI.net to parse the descriptions, a library which is also owned by my team.
It doesn't support 3.1 yet, but we're making progress towards it
Once the support is finalized, we should be able to add it here as well fairly quickly, which should also unblock a number of scenarios (like dictionaries/maps etc...)
Keeping this issue opened for now

@baywet Once OpenAPI 3.1 support is finalized, is support for generation of webhooks planned? I currently maintain https://github.com/octokit/webhooks.net manually, but am eager to switch over to automatic generation if possible.

@JamieMagee if by generation of webhooks you mean generating the models for the incoming requests, sure we could add that.
If you mean something else, can you clarify please?

@baywet yes, that's exactly what I am talking about. A top level webhooks property was added as part of the OpenAPI 3.1 spec¹:

Major Changes in OpenAPI Specification 3.1.0
...

• New top-level element for describing Webhooks that are registered and managed out of band

As of release v2.1.0² of the GitHub REST API description webhook schemas are included.

Thanks for clarifying!

Hello,
In the OpenAPI.NET repo, the issue about 3.1 support is closed.
Should we expect Kiota to support v3.1 soon?

Yes! It's absolutely something we'll start working on soon as there is a lot of demand for it!

We have some other priorities right now but this should be in the next bucket of improvements!

Have the priorities changed by now? 😄
Any timeline for 3.1 support?

adding a +1 for demand here - all our APIs are using OAI3.1 so having to down-convert to 3.0 is a little cumbersome. (also happy to help with contributing!)

No updated timeline to share at this point.
You can track the progress in the dependency with this milestone
Whenever a preview of the new version is available, we'll be able to start work in kiota.

Please make sure that when this is implemented it fully supports proper enums with number/string representation in all languages that generate real enums with real numerical values attached like this:

public enum Example {
  E1 = 1,
  E2 = 2,
  E3 = 4,
  ...etc.
}

The value should always be defined, never left to some automatic guess work based on the starting value too.

See #5165 for examples of what should be correctly outputted as your test case. In the case where the key is a string, languages should use a const static class to represent those if they don't support string/string (i.e. c#)

I've defined an example in #5165 as well of what the OpenAPI 3.1 version looks like.

@baywet is there some preview version that we can try? I have a 3.1 spec that I want to use.
I've installed 1.21.0-preview.202411210001 but still getting the error error generating the client: OpenAPI specification version '3.1.0' is not supported.

Hopefully you get v3.1 support working soon. Great work on this tool already!

Hey everyone,
I want to share an update on the progress, and our intended results here.

OpenAPI.net has released a preview of v2, which adds support for OpenAPI 3.1 🎉🎉🎉

We're using kiota (and other internal tools) to dog food this new version, so we can collect and address feedback on this new version before releasing a new major release (non-preview).

This has already allowed us to collect a lot of issues with one that's currently blocking kiota and is being worked on.

I have not opened a PR yet to reduce noise (but let me know if it would help you track progress), but my branch (feat/OAI-3-1) has ~150 failing unit tests, the vast majority caused by the bug mentioned above. Once this is fixed, we can think about previewing things in kiota (we don't need for all the feedback to be addressed as we can take a dependency on a preview release, and iterate on that).

Now, when we refer to "OpenAPI 3.1 support" it's usually helpful to break it down into:

• simply being able to parse an OAS 3.1 document, which will unblock a lot of you.
• implementing new features (new type array, webhooks, etc...) that are additive (non-breaking). We'll most likely rely on the feedback once a preview is out to drive priorities.
• implementing new features that are source breaking. We're already having internal conversations about a potential kiota v2, and what the scope would be. Input is always appreciated.

If during the testing phase we realize the basic parsing of OAS3.1 brings some breaking changes, we'll have to review the sequencing here.

I hope this update is positive news to most of you, I do not have any timelines to share, but I'll be happy to answer questions :)

Hi everyone,
I wanted to share an additional update on this topic.

The incubation of the preview version resulted in lots of feedback, which is gradually being addressed.
The main point of contention for kiota, being able to automatically detect the description format, has been addressed and released, which has allowed us to make additional progress in the migration of kiota itself.

I've started a draft PR at #5936

You'll see we're down to ~15 unit tests failing at this point. They are all caused by two dependencies: Microsoft.Plugins.Manifest and Microsoft.OpenApi.ApiManifest which depend on Microsoft.OpenAPI 1.X, causing assemblies loading confusion. I'll be working with the library owners to get them to upgrade to Microsoft.OpenAPI 2.X as well to unblock us.

Once that part is done, we might have additional adjustments to make since Microsoft.OpenAPI will have addressed additional feedback. And after that, we'll see what results we get from integration tests.

Hopefully this is good news for all of you! Happy end of the year celebrations!